Posts

Wrap-Up

Hello all,
This was indeed an exciting summer. During this summer, I initially implemented the elements along with their parsers and serializers, required to implement the MIX features. Then I implemented a MIX Registry to keep track of channels joined by a client, and sync the same information with their rosters. This Registry is responsible for returning an object of the joined channel, which can be used for various features like setting nick for the channel, sending messages, etc. Finally. I implemented basic functionalities for MIX in Swiften, along with a MIX Example client and MIX Mock Server to respond to clients. Let me explain the features I have added as part of GSoC'17 along with examples:

1.) Client querying MIX service for hosted channels: This allows my client to query server for hosted channels.

2.) Client querying for publish-subscribe nodes supported by MIX channel: This allows my client to query server for supported standard nodes for a MIX channel.

3. Client jo…

Week 9 & 10

Hello all,
We have a new design for MIX ! As proposed by mentors, we have a new implementation scheme for MIX involving MIX Registry, which will have access to all MIX objects for successfully joined channels. 
The new design allows requesting a MIX Registry from Client and detecting whether local server is supported.  It also adds XMPPRoster to be a part of MIXRegistry. A standard roster encoding is as follows: <itemjid='romeo@example.net'/> However, if a roster item is a MIX channel, the new encoding will be : <itemjid='balcony@example.net'><channelxmlns=‘urn:xmpp:mix:roster:0'/></item> Based on this, we now define a channel to be successfully joined or left based on the presence of channel JID in the user's roster. If a channel is successfully joined, a roster encoding with a channel element is added to user's roster. Similarly, when channel is left, roster encoding is removed from user's roster. 
In the upcoming weeks, I will …

Week 7 & 8

Hello all,
It has been productive two weeks ! I have added some features to MIX in Swiften. These two weeks, I have added the following features:
1. Registering and setting Nick by a MIX client: This feature allows a MIX user to set and register a nick for a MIX channel by sending IQ stanzas of the following type: <iqtype='set'from='hag66@shakespeare.example/UUID-a1j/7533'to='coven@mix.shakespeare.example'id='7nve413p'><setnickxmlns='urn:xmpp:mix:0'><nick>thirdwitch</nick></setnick></iq> This example shows an IQ stanza from a MIX client to a MIX channel asking to set nick "thirdwitch". Similarly, if a MIX channel supports registering nick (mix_nick_register), then client sends a register nick payload to the channel.
2. Requesting VCard of  a channel participant: A MIX client can now request a VCard of a channel participant by sending  an IQ request to bare proxy JID of the channel participant as foll…

Week 5 & 6

Hello !
These last two weeks I had actually started implementing MIX features in Swiften library along with unit testing. I have now implemented capabilities for a MIX client to join as well as leave a channel. Every MIX channel has a set of standard Publish-Subscribe nodes to which clients can subscribe. For example: message node (urn:xmpp:mix:nodes:messages) will contain a message sent to the channel, participants node (urn:xmpp:mix:nodes:participants) stores the list of participants and their associated nick, etc.
Therefore, a MIX client can send an XML to its own local server for joining a channel and subscribing to the nodes within the channel as follows:
<iqtype='set'from='hag66@shakespeare.example/UUID-a1j/7533'to='hag66@shakespeare.example'id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'><joinxmlns='urn:xmpp:mix:0'channel='coven@mix.shakespeare.example'><subscribenode='urn:xmpp:mix:nodes:messages'/><subscrib…

Week 4

Hello all,
This week was a productive week ! I completed all the elements required for MIX implementation along with their parsers, serializers, and unit tests. The elements completed this week along with their XML examples (taken from XEP) are as follows: Create Element: A client creates a channel by sending a simple request to the MIX service.<createchannel='coven'xmlns='urn:xmpp:mix:1'/>Destroy Element: A client destroys a channel using the destroy payload.<destroychannel='coven'xmlns='urn:xmpp:mix:1'/> Set Nick Element: The client sends a command to the channel to set / update the nick.<setnickxmlns='urn:xmpp:mix:1'><nick>thirdwitch</nick></setnick> Register Nick Element: The client sends a command to the channel to register the nick.<registerxmlns='urn:xmpp:mix:1'><nick>thirdwitch</nick></register> Update Subscription Element: The client can send a update subscription request …

Till Week 3 - Elements !

Hello all,
I am Tarun, a senior year student at IIIT Hyderabad, India. This year I was selected as a GSoC student by XMPP Standards Foundation to work on Mediated Information Exchange (MIX), which is intended as a replacement for Multi-User Chat (MUC). I'm being mentored by Tobias and Edwin. Let me begin by explaining why do we need MIX as a replacement for MUC ? In the years after MUC was designed, both Publish-Subscribe and Message Archive Managementhave been developed and it is desirable to reuse these building blocks (e.g., MAM can be used for message history) rather than using the less robust methods defined in Multi-User Chat .It is difficult to use MUC for building multimedia applications without undesirable adaptations.A number of use cases has emerged in group communication, which are explained here. I have started by implementing elements (payloads), which will be coming in / send out in the form of XML. Therefore, we need parsers and serializers for each payload to be a…