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?
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.
Connecting to some of the other discussion, it seems that the daemon is
really an application, not a library, and so is handled differently.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
