#10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

Tomeu Vizoso tomeu at sugarlabs.org
Fri Sep 24 03:16:01 EDT 2010


On Fri, Sep 24, 2010 at 09:12, Simon Schampijer <simon at schampijer.de> wrote:
> On 09/23/2010 03:30 PM, Tomeu Vizoso wrote:
>> On Mon, Sep 20, 2010 at 12:56, Paul Fox<pgf at laptop.org>  wrote:
>>> tomeu wrote:
>>>   >  On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
>>>   >  <martin.langhoff at gmail.com>  wrote:
>>>   >  >  On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso<tomeu at tomeuvizoso.net>  wrote:
>>>   >  >>  So the problem is that if you had to resync all state for each machine
>>>   >  >>  every time they wake up, you would use lots of bandwidth with the
>>>   >  >  (...)
>>>   >  >>  Another issue with this is that you not only want to resync presence,
>>>   >  >>  but shared activities also would need to resync their state.
>>>   >  >
>>>   >  >  Correct. My notes on the bug are probably unreadable -- it was late
>>>   >  >  last night, apologies.
>>>   >  >
>>>   >  >  What I mean to say is that we could
>>>   >  >
>>>   >  >  1 - explore the interaction between sleep timeouts and Salut resync
>>>   >  >  frequency for presence
>>>   >  >
>>>   >  >  2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual
>>>   >  >  collaboration session is running
>>>   >  >
>>>   >  >  I think #1 needs to be done regardless, as it'll improve behaviour
>>>   >  >  even if/when we our networking/suspend issues sorted. And some of the
>>>   >  >  issues in network/suspend interaction won't be easy to resolve.
>>>   >
>>>   >  I doubt there's much that can be done in Salut about it, should be
>>>   >  instead done inside Avahi. I would see how mDNS works, then look for
>>>   >  opportunities of tuning knobs in Avahi to speed up rediscovery:
>>>   >
>>>   >  http://tools.ietf.org/html/draft-ietf-dnsext-mdns-47
>>>   >
>>>   >  I'm going to ask around in case somebody has already thought of it and
>>>   >  can provide a shortcut.
>>>
>>> the laptop knows how long it was suspended, and this information could
>>> be made available to a resume hook (which almost exists, but not
>>> quite, in powerd) if it would be useful.  i.e., a a post-resume script
>>> could decide whether to kick the protocols to do something differently,
>>> if that was needed.
>>
>> Paul, what do you think about powerd implementing org.freedesktop.UPower ?
>>
>> http://upower.freedesktop.org/docs/UPower.html
>>
>> Regards,
>>
>> Tomeu
>
> UPower is available in Fedora >= 13 AFAIK. We are still stuck at the
> moment with F11. So, that road is meant as Future possibilities, right?

Not really, powerd could implement the same DBus interface. You would
need to backport something for Avahi to use it, though.

Regards,

Tomeu

> Regards,
>    Simon
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



More information about the Devel mailing list