[sugar] Issues with the presence service

Marco Pesenti Gritti mpg at redhat.com
Sat Jul 29 13:20:34 EDT 2006


> So how about this for a flow?
>
> - PS sees new "_tamtam._tcp" service advertised, sends ServiceAppeared
> signal
>
> - Home Page receives ServiceAppeared signal, looks through it's registry
> for Activities that can handle "_tamtam._tcp"
>
> - Home Page finds the TamTam activity can handle it, and asks some
> TamTam code to thumbnail and display the activity on the Home Page
>
> My point is that on the activities _themselves_ can know what service
> types the can handle, and how to handle those types.  We don't need a
> "default type" passed through the PS, because the local activity knows
> how to handle it.  For example, the browser uses "_web_olpc._udp" and
> "_olpc_model._tcp".  The Browser activity already knows that the
> _web_olpc._udp service is the "default" service for a browser activity,
> and it can tell the Home Page that without the PS getting involved.
>   

Ah! I had forgot the default type is just the name of the default 
service... I need a new brain.

>   
>>>> - 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()
>>                 self._chat_service = 
>> self._pservice.share_activity(self._activity,
>>                                 stype=ActivityChat.SERVICE_TYPE, 
>> address=addr, port=port)
>>     
>
> Hmm, maybe we should make the Activity base class handle the sharing?
> Because Activity objects already know their default service type, 

I think we should do that.
Btw there is join_activity/joinActivity in shell/PresenceService which 
seem to be unused?

> and we
> shouldn't be using "share_activity" to publish anything _except_ the
> default service type.
>
>   

I think that's not the case at the moment... so we should fix it.

There are probably other cases where you will want to "clone and 
republish" a service. That might not be frequent enough to deserve a 
specific API though, not sure.

> I wanted to get away from having create_service()/create_activity()
> calls that just create the service/activity and then wait for you to do
> something with it.  That's pretty useless and encourages bad habits.
> When you create a service, it should be published automatically because
> there's no legitimate reason I can think of that it shouldn't be
> published automatically.
>   

Yeah, that make sense.

Seems like we covered pretty much everything. We just need to go through 
this thread and fix up stuff...

Thanks,
Marco


More information about the Sugar mailing list