[sugar] Issues with the presence service

[Marco Pesenti Gritti]

Dan Williams wrote:
> On Sat, 2006-07-29 at 14:05 +0200, Marco Pesenti Gritti wrote:
>   
>> Dan Williams wrote:
>>     
>>> On Thu, 2006-07-27 at 11:43 +0200, Marco Pesenti Gritti wrote:
>>>   
>>>       
>>>> - There are places where I want to pass services around through dbus. We 
>>>> should use paths for this right? I couldn't find a way to recreate the 
>>>> objects other than the protected _new_object though.
>>>>     
>>>>         
>>> That's intentional.
>>>
>>> Just use the object path of the Service that the PS returned to you.  I
>>> removed the service serialization stuff because the Service's object
>>> path is essentially a pointer to the service, and that's what you send
>>> to the PS to have it operate on.
>>>   
>>>       
>> I'm not sure to understand this.... The use case is:
>>
>> 1 I have a sugar.presence.Activity in the shell
>> 2 I want to pass it to an activity (different process) through dbus. I 
>> currently do this with activity.object_path().
>> 3 From the activity process I want to call sugar.presence.Activity 
>> methods (get_id, get_services etc). To be able to do it I need to 
>> 'recreate' the object from his path. And I'm doing it using _new_obj.
>>     
>
> Ah, I understand.  Two ways, like you suggest.  In both cases, the other
> Activity process needs to have a PresenceService object (from
> sugar.presence.PresenceService) created for itself.
>
> Solution 1:
> Pass the object path from the Shell to the other activity process
> through dbus (use type 'o' for object paths rather than type 's' so they
> get validated correctly).  Add a "get()" call (or something like that)
> to the sugar.presence.PresenceService object that creates the
> Python-wrapped D-Bus object, and return it.  Pass the object path into
> get().
>
> Solution 2:
> Just pass the activity ID, and then call the
> sugar.presence.PresenceService's get_activity() method.  However, this
> isn't generic and therefore there's no easy way to get a Service or
> Buddy object, for example.
>
> I vote for #1 I guess.  There's a benefit to making IPC and RPC
> dead-easy for kids to do, but there's a minimal level of complexity with
> IPC/RPC anyway that we simply can't cover over.
>   

#1 sounds good to me too. This shouldn't be something frequently needed 
for writing activities anyway.

Marco