Most of the time I live in Sheffield in the UK. Over the past three years I've been studying Computer Science at Cambridge University, I graduate on the 29th of June 2006. I successfully applied to the Google Summer of Code project this year and I'll be spending three months working on the Java Jingle project.
Project Proposal: Java Jingle
I am interested in creating a Java implementation of the Jingle XMPP enhancement.
Benefits to Jabber:
Jingle represents an important development in open instant messaging, enabling XMPP clients to conduct voice calls across firewalls and NAT. Widespread use of Jingle will increase the attractiveness of open instant messaging.
A Java implementation of Jingle's VoIP features would enable more clients to take advantage of the features offered by this extension. This would help spread the use of Jingle and, as a result, the Jabber messaging system.
In addition, building multiple implementations of the same standard should help in fleshing out the specification and finding bugs in existing libraries.
- Java Jingle library.
- Classes to implement audio streaming.
- Documentation enabling client designers to easily make use of the library.
- A small number of example programs.
The aim of this project is to enable Java based cross-platform Jabber clients (such as Spark) to take part in voice calls with other Jingle enabled clients. This will be accomplished by a implementing Jingle (JEP-0166) and Jingle-Audio (JEP-0167) in the Java language.
The aim is to build a new library from the ground up, rather than porting Google's code (called libjingle) from C++ to Java. Existing libraries such as JavaSound and JSpeex will be used for audio capture, encoding, decoding and playback, while Smack should serve as a good basis for the XMPP communications.
In addition to the basic protocols described in the JEPs this project includes the implementation of a number of the classes that will be necessary for Java Jingle to be useful immediately to programmers. These are the classes necessary to actually encode, transmit and receive audio data.
Transport methods and media types will each be represented at coding time by an interface. Classes that facilitate a particular transport type will all implement the transport interface, while those that deal with a particular media encoding will all implement the media engine interface. Which particular implementing class will be used for any particular session will only be decided at run time.
As part of the project I will be implementing a number of classes that implement both interfaces, but it is important that other coders are easily able to add support for other transport and media types in the future. This design structure will ensure that it is easy to expand the functionality of Java Jingle as time progresses, as all they will need to do is write classes that implement these interfaces and plug them in to the existing system.
The start of the project will be delayed slightly as a result of my exams, which are in the middle of June. However, researching and designing this project will serve as a nice alternative to revision. I plan to build several prototype programs over the next few weeks and accumulate the knowledge that I'll need in order to properly design the library. A detailed design should be in place by the time of the mid-term evaluation. (June 26-30).
On the 29th of June I graduate and move back home to Sheffield. Once this is out of the way I have no other commitments for the summer and will be able to devote the next two months to implementing Java Jingle. This would be my job for the summer and I plan to treat it like one, working about 8 hours a day for 6 days a week. Testing will be carried out concurrently with coding, with test classes created to test each class. I have a small network at home which connects to the internet via NAT, so I should be able to completely test the code I write.
I plan to spend my time in the following way:
6 days - Create a small number of command line test programs to test library functionality, including classes enabling classes which implement the media engine interface to make use of the user's hardware (such as microphone and speakers).
5 days - Classes to negotiate a Jingle-Audio session.
3 days - Class implementing a transport interface for one transfer type (probably RTP).
4 days - Class implementing media engine interface for one audio encoding.
7 days - Support more audio encodings and transport types.
3 days - Documentation.
1 day - Adapt test programs to serve as examples.
With the rest of the time serving as contingency and to give me the occaisional rest. The later stages should mostly consist of building wrappers for existing transport and media libraries, and should be quite straightforward (depending on the documentation of these libraries). Negotiating a Jingle-Audio session in Java may well require some extensions to Smack, and could possibly take more time than scheduled. If I'm concerned about any part of the implementation of Java Jingle overrunning then it is probably these first stages.