[Portland] The Code

[Bryce Harrington]

On Thu, Feb 16, 2006 at 07:40:29PM +0100, Lubos Lunak wrote:
> > Well, at the application level it looks like it could be an optional
> > thing.  I.e., an app like Inkscape could simply try to init the dapi
> > service, and if it can't, then it assumes that functionality is not
> > available and goes on.
> 
>  On the other hand, the app could always include its own generic 
> implementation that it'd start if it fails to find any running. If it turns 
> out to be feasible to provide "complete" functionality even in the generic 
> implementation, apps then wouldn't have to bother with fallbacks at all.

Good point, that'd work too.  Such an app-specific install would need to
be runnable from an arbitrary location (if the app is installed to /opt
or whatever), and be able to use an arbitrary port location (so if more
than one app were doing this approach, they don't collide.)  Longer
term, this hopefully would become just a rare corner case.

>  Of course. And that's probably another reason against DBus, which AFAIK still 
> is considered unstable (as in "not frozen"). Versioning all the calls 
> shouldn't be that difficult though. OTOH I guess we shouldn't bother much 
> with API stability at least in the beginning.

Hmm, actually I think if we can address stability from the start, it'd
build valuable practices for this project for the long term.  Maybe it
could be as simple as distinguishing between "stable" portions of the
API and "experimental", and then just put everything into the latter.
(Then as we go, we could individually move services into "stable" only
when they've been sufficiently finished and peer reviewed, and we have
strong concensus that they don't need further changes.)

Bryce