[jdev] questions about gsoc: file transfer over jingle

Zhenchao Li cockneykevin at gmail.com
Mon Mar 22 08:02:24 CDT 2010

Hi, everyone!
    I'm a graduate student studying computer science and I've been exploring
both the XEPs concerning jingle file transfer and playing with the gajim
client's source code for the last 6 weeks. Since gajim already has the
ability to handle the jingle protocol and establish socks5 bytestream to
transfer file, implementing file transfer over jingle for gajim shouldnt' be
too difficult. There are just several things I don't quite understand and I
need your advice :

  As far as I know the jingle protocol is kind of similar to the original
stream initiation(xep-0095) conceptually. Apart from jingle being a newer,
more general session negotiation protocol(general in the sense that there
are already video, voice calls applications built on jingle) and SI
practically being used only by SI file transfer(xep-0096), what are the
advantages that jingle has over SI? Surely there are already clients that
has support for jingle file transfer(pidgin, gtalk) so we definitely will
see more clients implementing this, but, is there anything extra that jingle
has brought us so we can improve the file transfer process? What's the
rationale behind implementing file transfer over jingle given SI file
transfer already works fine?

  Also I've talked to asterix about some extra features I want to implement
in gajim. The first one is channel encryption. The only protocol I find
relevant is XTLS, which says it has already expired here. So it seems there
will be no standard way to implement this feature, right? Is there any
possibility this "XEP" will become a draft someday? Or is there any standard
way to encrypt the channel in the XMPP stack? The second feature that I want
to implement is transferring multiple files in one shot. But it seems that
according to jingle file transfer the receiver has to accept file transfer
one by one anyway. So I'm considering archiving the files and then send it.
But this is not accepted by everybody. The main argument being the receiver
does not know he/she has to unzip the archive. What I think is that this is
rather more related to how the client reacts to events like drag and drop of
several files. If the user is notified that files will be archived before
they are sent, I don't think he/she will be confused. So, what's your
opinion? I'd like to hear it:-) . Another feature I want to implement is
jingle IBB transport method. This is according to XEPs a must but for some
reasons it is not in gajim. After implementing this feature failed file
transfer attempts should fall back on IBB file transfer.

  These are some initial thoughts. Comments, advices, suggestions are all

  I'm pursuing a master of science degree in Fudan University, China. I'm
comfortable with C, C++, perl. And I love Python and lisp! I have played
with the linux kernel, netsurf the web browser and some other open source
projects, been a heavy user of open source softwares. I really hope I can do
something this summer to further improve my skills and contribute to the
XMPP community. You can find me  as fantasticsid on irc, jabber.com, and
also the blog and email below.

Homepage:   www.fantasticsid.com
EMAIL:         fantasticsid at fantasticsid.com cockneykevin at gmail.com
IRC:             fantasticsid
Jabber:         fantasticsid at jabber.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20100322/526e58ae/attachment.htm>

More information about the JDev mailing list