[sugar] How to handle application protocols

[Tomeu Vizoso]

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,
> etoys?)

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,
right?

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?

Tomeu