[sugar] How to handle application protocols
Wed Oct 10 03:37:48 EDT 2007
On Wed, 2007-10-10 at 00:01 +0200, J.M. Maurer wrote:
> On Tue, 2007-10-09 at 23:52 +0200, Marco Pesenti Gritti wrote:
> > On 10/9/07, Eben Eliason <eben.eliason at gmail.com> wrote:
> > > > I can see that happening for python code. However, Write is part Python,
> > > > part C++. The Python part depends on a specific version of the C++ part,
> > > > so you can't just send over the python part and expect it to work.
> > > >
> > > > Now we don't track the non-python dependencies for an activity anywhere
> > > > as far as I know, so I don't see this working in practice.
> > >
> > > This is really just an extension of the bundle transfer idea, by which
> > > anyone should be able to join an activity on the mesh they don't yet
> > > have. There is overhead involved, but bundles are self-contained
> > > largely for reasons like this. If the bundle has a newer version,
> > > then it should be simple enough to transfer the entire bundle from A
> > > to B. Assuming the bundle contains the C++ component, what's the
> > > complication?
> > I think the c++ component (libabiword) is currently installed in the system.
> Exactly; libabiword is not part of the Write bundle. We could do that
> ofcourse, but then other applications can't benefit from the libabiword
> code (such as a Develop activity for example).
> I suspect more activities depend on code not in the bundle (browse,
What if we ship libabiword as part of the system (rpm) but .xo bundles
provide their own abiword plugins? AbiCollab is implemented as a plugin,
Alternatively, things could work as today (rpms for libabiword and
libabiword-plugins), but bundles can provide their own plugins that can
override the system-wide plugins?
Is this feasible?
More information about the Sugar-devel