[sugar] Issues with the presence service
Marco Pesenti Gritti
Sat Jul 29 09:11:51 EDT 2006
>> - 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.
We are already doing this locally... I think we need to advertise it in
the PS though. Otherwise how do you associate the right activity icon
in the home page for remote activities (published by someone and not
joined) ? And, more importantly, how do you open a remote activity if
you don't know his 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.
That make sense now. Though I think it was not working... a bug
somewhere I guess.
>> - 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
Right, my point was more than we need convenient way to do it (and one
that doesn't need a comment to clarify what is going on)...
# Ok, there's an existing chat service that we copy
# parameters and such from
addr = service.get_address()
port = service.get_port()
Btw, this is missing in the browser activity atm. We need to fix that...
(or provide this for every activity).
More information about the Sugar-devel