[sugar] Issues with the presence service

[Dan Williams]

On Thu, 2006-07-27 at 11:41 +0200, Marco Pesenti Gritti wrote:
> Hi,
> 
> yesterday I got back most of the network related functionality in sugar. 
> It's still easy to break and needs cleanup. Anyway, here are some issues 
> I had:
> 
> - We need a way to get basic informations about the activity, before 
> joining it,  the title at very least. Might just use the service 
> properties for this? Maybe a get_title api in Activity?

Right; I guess we need to have the PS add some default attributes to the
activity advertisement.  We already do this for the "address" of the
service, since when you resolve the service you get the publisher's
address (unicast), not the communication address, which is a problem for
multicast services.

> Btw I'm somewhat confused by this in Activity:
> 
> def get_icon(self):
>     return self._buddy.getIcon()

C&P error

> - We need a way to get the activity default type, so we can figure out 
> which activity to associate to the service.

Right; I think we should do this locally.  We have to have something
like .desktop files, or hardcoded in the activities init routine, what
it's default type is.  We already do that when the activity registers
with the shell (I think?), so we need to allow the HomePage to access
that.  I'm not sure if the PS should know about the default type.

> - I had to make some hacky changes to share_activity. For udp services 
> we need to publish the group IP in the properties (unless there is a 
> better way?). Have a look at how I'm doing it currently... I'm sure we 
> can clean it up.

Shouldn't the PS already be adding the "address" of the group into the
attributes of the message?  The address returned by get_address() on the
service should _always_ be the communication address of the service, not
the unicast address of the person who published it (which is what
get_source_address() is for).  I thought this worked already.

> - There seem to be no way to join an activity other than manually 
> duplicate the service. Also should we provide this rather than have 
> every activity to reimplement it? In sugar.activity.Activity or maybe 
> even directly in the shell...

Well, we _have_ to create a new service when we join the activity, since
we need to change the source address for the service anyway.  Even if we
receive a service from the network from somebody else, that service is
"somebody else's" service, and _not_ ours.  We have to create a new
service, cloned from the original service, and publish that instead,
because that uses our local information.

Dan