[sugar] Python coding conventions

[Ian Bicking]

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 | ianb at colorstudy.com | http://blog.ianbicking.org