On Thu, 2006-09-28 at 11:12 -0500, Ian Bicking wrote: > Dan Williams wrote: > > On Thu, 2006-09-28 at 10:20 +0200, Marco Pesenti Gritti wrote: > >> Ian Bicking wrote: > > <snip> > >>> I guess the only other issue might be with the file layout, a little > >>> related to distutils. For instance, why is there > >>> source/sugar/services/presence and source/sugar/sugar/presence ? > >>> > >> source/sugar/services/presence is the dbus service. It's supposed to be > >> private API and it's installed in the datadir rather than in > >> site-packages. source/sugar/sugar/presence is the public API, installed > >> in site-packages. > > > > Slight correction here: > > > > sugar/services/presence is the D-Bus service, which could be written in > > C, C++, Mono, haskel, python, etc. It provides a _public_ D-Bus API, > > and should not go in a python-specific directory because stuff other > > than python uses it. If you write a C activity, you'll use it, just > > like you would use the Shell (which should also not go in > > python-specific directories). None of this could can or should be used > > directly by a python program, as the only _public_ interface for it is > > the D-Bus API. > > Is this the same as saying that sugar/services/presence is the presence > daemon, and sugar/sugar/services/presence is the client code to access > that daemon?
That's a good point; however somebody creating sugar apps in Python should never have to see, nor care, about sugar/services/presence stuff. > If so, can these be named more distinctly? I think the potential for > confusion is obvious ;) Maybe presencemanager or presencehub or > something like that. Or not use sugar/sugar/services, but use some > other name for the client APIs. The client APIs are intended to be a thin wrapper around the D-Bus API. If you look at it from a D-Bus perspective, which you should, the nomenclature being used makes sense. Perhaps we want to wrap the D-Bus API in a more pythony way. Dan > Connecting to some of the other discussion, it seems that the daemon is > really an application, not a library, and so is handled differently. _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
