[Sugar-devel] File transfer in Telepathy

[Greg Smith]

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?
> 
> 
> "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".

> 
> 
> "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?

> 
> 
> 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.
> 
> 
>