[Sugar-devel] File transfer in Telepathy

Fri Dec 5 10:13:53 EST 2008

On Fri, Dec 5, 2008 at 9:43 AM, Greg Smith <gregsmitholpc at gmail.com> wrote:
> Hi Guillaume,
>
> Thanks for reading it over and commenting.
>
> I dropped the sugar list and moved this to devel. If someone (Tomeu?)
> thinks it should be back on Sugar devel, forward as needed.
>
> See original threads here:
> http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010122.html
> and here:
> http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010096.html
>
> FYI Requirements with "should" are nice to have but not critical (AKA do
> the "must" ones first and the "should" ones only if there is time).
> There was a request to follow RFC guidelines
> (http://wiki.laptop.org/go/9.1.0_Collaboration_Requirements#Requirements_Definition)
>  but I'm not that formal yet.
>
> Can you link to any documentation on your plans in the specifications
> section? Links to the code itself are OK or whatever you have available
> without too much added work. I added a link to your GIT sample script
> already.
>
> More comments inline below.
>
> Thanks,
>
> Greg S
>
> Guillaume Desmottes wrote:
>> Le jeudi 04 décembre 2008 à 13:42 -0500, Greg Smith a écrit :
>>> Hi Guillaume,
>>>
>>> Thanks for following up on this!
>>>
>>> I collected all the known requirements on this here:
>>> http://wiki.laptop.org/go/Feature_roadmap#File_sharing
>>>
>>> [...]
>>> Comments and questions welcome.
>>
>> Few comments then.
>>
>>
>> "Should allow moving an object to any XO visible over the network (AKA
>> pingable) regardless of whether they are visible in the Neighborhood
>> (due to bugs in collaboration or someone not collaborating or any other
>> barrier which does not prevent ping)."
>>
>> I'm wondering how would be the UI for this? How can I send a file/object
>> to someone that I'm not seeing?
>>>From a Telepathy pov, you have to see the contact (as online) to send
>> him a file. One of the improvement I suggested during my Sugar Camp talk
>> was to add UI allowing users to add buddy based on their JID (like you
>> do with your classic IM client). Then if he accepts you, you'll see it
>> in your neighbourhood view when he's online. That means you can
>> potentially add any one even if you are not seeing him atm (because of a
>> bugged shared roster for example).
>> If that what you mean or am I totally missing the point of this
>> requirement?
>
> GS - I like that idea of naming the other XO and seeing them every time.
> I like it a lot! Should I create a new requirement for it? We should
> definitely do that if possible. Let me know how close we are.
>
> I put this requirement in to try and have a fall back in case other XOs
> are not visible in the Neighborhood. One of the oddities of our
> "presence" concept is that the users are usually sitting right next to
> each other. That's different than the typical corporate collaboration
> where people are in different offices.
>
> Its frustrating when you can see the kid next to you but your computer
> can't :-(
>
> If others can't solve all our problems of "presence" I want to have a
> fall back. The foolish, worst case is to ask kids to open terminal find
> their IP address, then ping each other then type that IP in to the GUI
> to share files or otherwise collaborate.
>
> Anything we can do to make that happen in the GUI (e.g. your idea above)
> would be great, as a fall back in case file transfer by existing
> "presence" mechanisms is not working.
>
> Eben,
>
> Can you comment on GUI options and let me know if you have any questions?

I don't think I have many questions, but maybe Scott and I should
catch up on this topic soon.  I recall that he had a few concerns for
me to take into account, so I want to be sure I have the whole picture
before I work on a mockup.

>> "Should support queuing a file for transfer later. That is, add support
>> for asynchronous sharing over time : the sharing of an effort should not
>> require everyone to be online at once."
>>
>> Do you want a "send this file to Bob as soon he's online" button? Then
>> it's a pure UI thing, Telepathy (obviously) requiers the contact to be
>> online when sending the file to him.
>
> GS - I think this was SJ's idea. Its clever but not critical. If Eben
> can design (and code?) the UI for it and its otherwise free with your
> code, we can consider it. I would definitely put it below the above
> items. I downgraded it to "may".

This is an interesting idea, though I agree it's not critical.  It
might have great usefulness once we add groups, since we'd like to
support an action such as "send this file...to my class".  In such an
instance, Alice might not be in class the day I attempt to send it,
and it could be queued until later; or, she could simply miss out on
the transfer requiring manual intervention next time she's around.

It amounts to showing "everyone" (for some definition of everyone) in
the list when initiating a transfer, instead of just those who are
online, and then setting up some code when we get the buddy-online
(not sure what it's actually called) signal which checks a queue and
initiates the transfer when they arrive.

I have added a new requirement myself, though, related in a way to the
above: should provide resumable transfers, so that intermittent or low
quality connectivity doesn't cause transfers to fail permanently.  I
made this a should (I'm tempted to make it a must, actually).  I think
that, given our network behavior, it's critical to make this system as
robust as possible, and the ability to resume transfers would go a
long way to making them less painful in the face of a hostile network.

>> "Enable automatic activity downloading for shared activities that aren't
>> installed on the joining machine".
>>
>> This would need some design work but should be possible I think.
>> Basically we need a way for the joiner to say to the initiator "I'd like
>> to join this activity but I don't have it. Could you send it to me
>> please?".
>
> GS - Another SJ idea. Sorry I left out the priority. I marked it "may"
> to mean its lower than "should". USeful but not critical right now.
>
>>
>>
>> I'd like to know exactly which meta data should be available when we
>> receive an incoming file transfer.
>> http://wiki.laptop.org/go/Specifications/Object_Transfers#Information_to_show
>> contains some.
>> Especially, I think we should distinct mandatory and optional
>> informations.
>
> GS - I added that URL to the specifications section.
>
> Eben, can you get Guillaume the details he needs ASAP or let me know who
> to follow up with?

I'll take a look at that page and try to make the distinction between
mandatory and optional.  The mockup hasn't been changed for a while,
so I think we really care about the info needed to match the images on
that page.

- Eben

>> All the others points seems perfectly reasonable and should be doable.
>>
> GS - Awesome! When this is ready, someone should go to School IE 41050
> Virgen de Lourdes - Islay, Peru
> http://www.maplandia.com/peru/arequipa/islay/ to upgrade them, show them
> how to use the mesh and how to transfer files :-) Sebastian S?
>>
>> Telepathy uses as much standardised protocol as possible. So maybe it
>> would be good to add a requirement saying the file transfer
>> implementation has to use standard file transfer protocol to ensure
>> interoperability with existing IM clients. That way, Sugar will be able
>> to exchange files with any other jabber and xmpp link-local desktop
>> client (as Empathy, Pidgin, iChat, etc).
>
> GS - Sounds like a good idea to me but I think you need to list the
> "standard file transfer protocols". I'd like to hear other comments. My
> first impression is that we can make it a "should" requirement if you
> can give me a list of protocols and a few sample applications.
>
>>
>>
>> Regards,
>>
>>
>>       G.
>>
>>
>>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>