The next step is to implement a receiver module for the PDA so that the MMS peer is able to achieve two-way messaging. In the following discussion we give a flowchart to decode the message if retrieved directly from the MMS proxy-relay using the HTTP GET method. This flowchart will be helpful for the implementation of the module to receive MMS messages on a PDA.
Figure 20 is a flowchart of the decoding process for the main header of the "m-retrieve-conf" (MMS client transaction specification, 2002) message of content type application/vnd.wap.multipart. related . It assumes that after the sending of the HTTP GET request, the MMS proxy-relay will return with a message along with the HTTP headers. The HTTP headers can be easily skipped by looking for two consecutive carriage returns and line feed pairs. After this the encoded MMS header starts which are read byte by byte till the byte of number of body parts is reached.
The "Read uintvar length" process needs some further explanation. Note that this value can be variable in length and uses the variable length unsigned integer encoding as discussed in the design and implementation section. A byte follows if the byte currently read has its most significant bit equal to 1. So one knows how many bytes to read without actually knowing the length of this value. Also note that the byte denoting number of body parts used after the main headers is going to be deprecated and might not be the perfect way to reach an end. This should not affect the decoding though, as the last decision box should be reached only after all the headers, their parameters, and their values have been read. This flowchart assumes no user -defined headers.
The To and Subject header values can have length bytes preceding the value. This length value could either be 1 byte or encoded using variable length unsigned integer encoding. Its length in the latter case is followed by the charset for the following text.
In Figure 21 "hLen" is the length of the whole header and "cLen" is the length of the Content Type header. Note that the Content Type header in the body part is just the value of this header and is not preceded by a code for the header name .
The service client plug-in feature refers to the client download option. The current implementation assumes the client for a service to be there on the peer. As the peer already has core Jxta functionalities, it is a good idea to use them to provide this feature. The advertisements of a service could specify the location of a client, which could be transferred over to the peer and dynamically loaded. This is possible in Java using the API for loading classes. To enable this feature one could create a Jxta service that has clients registered with it.
With the existing application framework, PDA to PDA MMS messaging can be easily enabled using the Jxta messaging layer. As PDAs are more capable than mobile phones, even video could be enabled for PDA to PDA messaging. All it would mean is using another media type in the SMIL or the encoded message.
To account for different PDAs communicating, the user agent profile specification (UAProf; WAP UAProf, 2002) could be used for capability negotiation. The UAProf schema for MMS characteristics (client transactions) could be adapted to the PDA situation. The XML messaging layer for Jxta would enable the use of this XML scheme effectively.