my image of mChat is very similar to the Karol one. before all, excuse me for my english!
so, I've working for about 2 months on a J2ME chat application with jabber, and working on the code (a chat is a chat so the requirements are known!) I found some problems:
- a lot of phones (and wap gateway...) have a limit of 30KB, so for me we don't have to exceed this limit, or the application will'be usable for not many devices.
- the implicit mechanism to do chat is socket, but the protol support in the J2ME specification devices is not requested, so when I try to use it in the nokia & siemens dev toolkit, the emulation gives me this exception "the protol does not exist"!!!! wonderful ;-) i'm going to kill me when i see that message. The devices that support socket in j2me are 2/3 motorola and other high costs and new devices. (the mechanism to speak directly with jabber is socket and only socket for me, or not?)
The idea to workaround it, is to do a polling with http connection (not standard and not directly applicable to jabber, we need a proxy component), and send and receive data in syncronous mode, but it's not very elegant... (and we pay money for connection polling also!!!)
- another problem, honestly, is xml jabber parser in a j2me device, the smaller takes 10Kb, and under the scenes there is also a character stream reader handled in a separate thread (it's asynchronous in notification of message), so we have 3 or more thread: the midlet, the xml parser, and the char reader from connection (if it's socket), at this point in a multithreading environemnt, it's very difficult to work and the devices for my experience look very different... this solution it's hard to mantain and fix bugs.
so, what to do?
I take a decision at this point (2 weeks ago), but this is a crucial decision, and I want to know your opinion about this:
I make a proxy application (a simple servlet) that handles the phones, dispatches message to jabber, mantain polling session, count the message sent.
The client speak with jabber message sent to the servlet, they are forwarded by the servlet to jabber, and a http polling is used by the phone to receive the message serialized (serialization is not implemented in j2me, so i do the object serialization with my hands ;-)
Now the midlet (no xml parser, no crash, very fast) work in the same mode on all emulators (25kb) but it doesn't work directly with jabber.
Ah, I've no problem to give the code to sourceforge community, so we have a starting point, but my decision to make a proxy is the right decision? it's a good question...
so, let me know your opinion!
Franz.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Franz,
Well thanks for the input.
As regards to teh project we need to develop it on MIDP.So we need to look at MIDP support for sockets and network communication.
And your proxy question,well http connections for a chat,well if you are going to have one http connection for each request of data(communication with jabber), the resources are gonna be used a lot,esp on small scale devices like phones etc.I would not say that your approach is wrong in using a proxy,but it would not be advisable for a connection and data oriented application like chat on a small scale device.
Franz, does jabber provide UDP sockets , that might lead to a different approach.Do UDP sockets work on mobile devices u mentioned ?
About using MIDP :-
While MIDP is a specification to be supported by all MIDP compliant devices,now if sockets are supported by MIDP,they should be supported by compliant device.We need more information on this.
Regards,
Amit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm afraid Jabber supports only TCP, not UDP sockets. Next, MIDP 1.0 specifies device MUST support HTTP and MAY support any other protocol. As I said, Siemens wrote in its specification that its phones support sockets. I also heard about Nokia 6800 which supports ones. Sockets MUST be supported if the phone support MIDP 2.0.
Regards,
Karol
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, We should make a list of devices and find out more on this area.
Whats the latest MIDP spec ?
will check support for sockets /devices etc and report back to the forum.
Cheers,
Amit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the idea of building a proxy is good, but should not be part of this project. And if I were to build such a proxy I would make a Jabber gateway for WAP, so that the users dont have to install a client.
A work around for the problem of using raw sockets instead of http is suggested here: http://wireless.java.sun.com/midp/questions/rawsocket/. I havent tested this, but I think we should. My Nokia 6310i is still being repaired (6 weeks and still waiting), so I dont have the opportunity. We could consider going for MIDP 2.0, but Im not in favour of this.
Regards
Jostein Leira
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hmmmm from reading the threads we r in planning mode still?
Just wondering if I need do anything yet? If not
someone please send out an email ( sf maillist )
once things are assigned
thx :)
My 2 bits, I think we should stick with MIDP 1.0 because MIDP 2.0 devices probably won't hit the streets until end of summer at earliest. Even though that isn't far off the most users will probably still have MIDP 1.0. As well josteinleira and myself already have access to MIDP 1.0 hardware so easier for us to test on actual devices. Should be hard to port to MIDP 2.0.
From my experience its really up to the carrier if they support other protocols other then HTTP
for MIDP 1.0.
I mean really I guess really comes down to protocol support. We need to design the protocol classes in way we can easily rip out and plug in
new protocols. Granted it is mobile with limited memory the user ( the one who compiles it )
chooses which libraries to leave and changes a setting in the code to select the appropriate protocol ---> HTTP, socket, udp... etc
With this mind maybe start with HTTP first it should work with everything.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was going through some articles on networking and MIDP , agre witha suggestion above that we shuld first try things with HTTP(we need to excahnge XML data parse it and comprehend it).
What we could do is keep this communiation module seperate in the architecture and we later we could replace it with a newer method of communication.
In one of the articles on sockets its mentioned that the implementation depends on the vendor and network, MIDP was designed to be portable across devices, I think first we should get the jabber mchat client working with HTTP on all MIDP devices and then maybe customise it in later version to use different communication modes based on vendors/netwroks etc.
Regards,
Amit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been thinking carefully about protocols and - you see - Jabber is the best choice. Why? We are indenpendent from our servers crashes, lots of free servers are open for us. Notice, that there aren't any IM networks using HTTP - this or another always uses sockets (no matter if port No. 1356, 9045, 13472, 3346 -it isn't HTTP). So, the only thing we can do is to make a HTTP <-> socket proxy for phones which don't support sockets. If we decide to, I think we should make the main project 'socket-enabled', and few persons should do a proxy. Of course, we can make our HTTP network - 'from zero', but where we can host it? And won't it be so slowly? Waiting for ideas.
Regards,
Karol
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well Karol we could do what u say ... make http access for non-socket phones.
Does Jabber not have an HTTP interface ?
If it does not then we do have a problem , building and hosting an http proxy.
Why dont we generate a matrix of phone types and the networking protocols enabled in them.
This should give us an idea of what is popular sockets/http.
- Amit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is large number of J2ME-enabled phones, so doing the matrix is hard job, but I can tell you, that there are only few phones with sockets, against to maybe hundreds with HTTP. For example, from Nokia phones only Nokia 6800 supports sockets. No, Jabber servers don't provide HTTP interface (as I know). But, with time, sockets will become most popular.
And, check out PHP-jabber-class - or PHP-class-jabber (I don't know) - it migh be an idea for proxy.
Regards,
Karol
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok i shall check out the proxy based model,where we mchat speaks HTTP to the proxy and the proxy ,speaks the jabber protocol with the jabber server and relays the result back in HTTP.
Ill see if we could host a free proxy somewhere or if there is an existing gateway for jabber available.
Regards,
Amit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found soem SOAP-HTTP support for jabber servers.Could we find out more on this please.
Im not too sure if we could use soap,for MIDP,if a toolkit is not available we will have to build a soap toolkit for MIDP then9which is a mini project in itself).In that case we could have 3 teams (1 working on the SOAP toolkit,2nd on the http proxy to jabber -server communication and a third on the user interface).Well Karol has to decide this its just my suggestion
If we do not use SOAP, we have to design a light-weight HTTP based protocol, or we could send the jabber-xml over http to the proxy.The proxy could establish socket based communication with jabber and send back the response to the client.
This could take very long s this involves holding a request,parsing data,communicationg with the jabber server,parsing the response from teh server and then sending data over HTTP back to the MIDP client.
Another issues is hosting the proxy server,I do not think there are free sites with java support.
Regards,
Amit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting soap is something pioneered by Microsoft, Microsoft and opensource do not usually go in the same breath...
I am interested in helping with the user interface (the easy part i admit!)
I will try to help with planning, not my strong point unfortunately!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
my image of mChat is very similar to the Karol one. before all, excuse me for my english!
so, I've working for about 2 months on a J2ME chat application with jabber, and working on the code (a chat is a chat so the requirements are known!) I found some problems:
- a lot of phones (and wap gateway...) have a limit of 30KB, so for me we don't have to exceed this limit, or the application will'be usable for not many devices.
- the implicit mechanism to do chat is socket, but the protol support in the J2ME specification devices is not requested, so when I try to use it in the nokia & siemens dev toolkit, the emulation gives me this exception "the protol does not exist"!!!! wonderful ;-) i'm going to kill me when i see that message. The devices that support socket in j2me are 2/3 motorola and other high costs and new devices. (the mechanism to speak directly with jabber is socket and only socket for me, or not?)
The idea to workaround it, is to do a polling with http connection (not standard and not directly applicable to jabber, we need a proxy component), and send and receive data in syncronous mode, but it's not very elegant... (and we pay money for connection polling also!!!)
- another problem, honestly, is xml jabber parser in a j2me device, the smaller takes 10Kb, and under the scenes there is also a character stream reader handled in a separate thread (it's asynchronous in notification of message), so we have 3 or more thread: the midlet, the xml parser, and the char reader from connection (if it's socket), at this point in a multithreading environemnt, it's very difficult to work and the devices for my experience look very different... this solution it's hard to mantain and fix bugs.
so, what to do?
I take a decision at this point (2 weeks ago), but this is a crucial decision, and I want to know your opinion about this:
I make a proxy application (a simple servlet) that handles the phones, dispatches message to jabber, mantain polling session, count the message sent.
The client speak with jabber message sent to the servlet, they are forwarded by the servlet to jabber, and a http polling is used by the phone to receive the message serialized (serialization is not implemented in j2me, so i do the object serialization with my hands ;-)
Now the midlet (no xml parser, no crash, very fast) work in the same mode on all emulators (25kb) but it doesn't work directly with jabber.
Ah, I've no problem to give the code to sourceforge community, so we have a starting point, but my decision to make a proxy is the right decision? it's a good question...
so, let me know your opinion!
Franz.
Hi Franz,
Well thanks for the input.
As regards to teh project we need to develop it on MIDP.So we need to look at MIDP support for sockets and network communication.
And your proxy question,well http connections for a chat,well if you are going to have one http connection for each request of data(communication with jabber), the resources are gonna be used a lot,esp on small scale devices like phones etc.I would not say that your approach is wrong in using a proxy,but it would not be advisable for a connection and data oriented application like chat on a small scale device.
Franz, does jabber provide UDP sockets , that might lead to a different approach.Do UDP sockets work on mobile devices u mentioned ?
About using MIDP :-
While MIDP is a specification to be supported by all MIDP compliant devices,now if sockets are supported by MIDP,they should be supported by compliant device.We need more information on this.
Regards,
Amit
Hi, Amit,
I'm afraid Jabber supports only TCP, not UDP sockets. Next, MIDP 1.0 specifies device MUST support HTTP and MAY support any other protocol. As I said, Siemens wrote in its specification that its phones support sockets. I also heard about Nokia 6800 which supports ones. Sockets MUST be supported if the phone support MIDP 2.0.
Regards,
Karol
So, We should make a list of devices and find out more on this area.
Whats the latest MIDP spec ?
will check support for sockets /devices etc and report back to the forum.
Cheers,
Amit
So MIDP 2.0 which is the latest supports sockects, but none of the phones supports MIDP 2.0...
Hi Folks
I think the idea of building a proxy is good, but should not be part of this project. And if I were to build such a proxy I would make a Jabber gateway for WAP, so that the users dont have to install a client.
A work around for the problem of using raw sockets instead of http is suggested here: http://wireless.java.sun.com/midp/questions/rawsocket/. I havent tested this, but I think we should. My Nokia 6310i is still being repaired (6 weeks and still waiting), so I dont have the opportunity. We could consider going for MIDP 2.0, but Im not in favour of this.
Regards
Jostein Leira
hmmmm from reading the threads we r in planning mode still?
Just wondering if I need do anything yet? If not
someone please send out an email ( sf maillist )
once things are assigned
thx :)
My 2 bits, I think we should stick with MIDP 1.0 because MIDP 2.0 devices probably won't hit the streets until end of summer at earliest. Even though that isn't far off the most users will probably still have MIDP 1.0. As well josteinleira and myself already have access to MIDP 1.0 hardware so easier for us to test on actual devices. Should be hard to port to MIDP 2.0.
From my experience its really up to the carrier if they support other protocols other then HTTP
for MIDP 1.0.
I mean really I guess really comes down to protocol support. We need to design the protocol classes in way we can easily rip out and plug in
new protocols. Granted it is mobile with limited memory the user ( the one who compiles it )
chooses which libraries to leave and changes a setting in the code to select the appropriate protocol ---> HTTP, socket, udp... etc
With this mind maybe start with HTTP first it should work with everything.
oops I meant to say shouldn't be hard to port to midp 2.0
I was going through some articles on networking and MIDP , agre witha suggestion above that we shuld first try things with HTTP(we need to excahnge XML data parse it and comprehend it).
What we could do is keep this communiation module seperate in the architecture and we later we could replace it with a newer method of communication.
In one of the articles on sockets its mentioned that the implementation depends on the vendor and network, MIDP was designed to be portable across devices, I think first we should get the jabber mchat client working with HTTP on all MIDP devices and then maybe customise it in later version to use different communication modes based on vendors/netwroks etc.
Regards,
Amit
Hi, everybody!
I've been thinking carefully about protocols and - you see - Jabber is the best choice. Why? We are indenpendent from our servers crashes, lots of free servers are open for us. Notice, that there aren't any IM networks using HTTP - this or another always uses sockets (no matter if port No. 1356, 9045, 13472, 3346 -it isn't HTTP). So, the only thing we can do is to make a HTTP <-> socket proxy for phones which don't support sockets. If we decide to, I think we should make the main project 'socket-enabled', and few persons should do a proxy. Of course, we can make our HTTP network - 'from zero', but where we can host it? And won't it be so slowly? Waiting for ideas.
Regards,
Karol
Well Karol we could do what u say ... make http access for non-socket phones.
Does Jabber not have an HTTP interface ?
If it does not then we do have a problem , building and hosting an http proxy.
Why dont we generate a matrix of phone types and the networking protocols enabled in them.
This should give us an idea of what is popular sockets/http.
- Amit
Hi,
There is large number of J2ME-enabled phones, so doing the matrix is hard job, but I can tell you, that there are only few phones with sockets, against to maybe hundreds with HTTP. For example, from Nokia phones only Nokia 6800 supports sockets. No, Jabber servers don't provide HTTP interface (as I know). But, with time, sockets will become most popular.
And, check out PHP-jabber-class - or PHP-class-jabber (I don't know) - it migh be an idea for proxy.
Regards,
Karol
Ok i shall check out the proxy based model,where we mchat speaks HTTP to the proxy and the proxy ,speaks the jabber protocol with the jabber server and relays the result back in HTTP.
Ill see if we could host a free proxy somewhere or if there is an existing gateway for jabber available.
Regards,
Amit
I found soem SOAP-HTTP support for jabber servers.Could we find out more on this please.
Im not too sure if we could use soap,for MIDP,if a toolkit is not available we will have to build a soap toolkit for MIDP then9which is a mini project in itself).In that case we could have 3 teams (1 working on the SOAP toolkit,2nd on the http proxy to jabber -server communication and a third on the user interface).Well Karol has to decide this its just my suggestion
If we do not use SOAP, we have to design a light-weight HTTP based protocol, or we could send the jabber-xml over http to the proxy.The proxy could establish socket based communication with jabber and send back the response to the client.
This could take very long s this involves holding a request,parsing data,communicationg with the jabber server,parsing the response from teh server and then sending data over HTTP back to the MIDP client.
Another issues is hosting the proxy server,I do not think there are free sites with java support.
Regards,
Amit
Interesting soap is something pioneered by Microsoft, Microsoft and opensource do not usually go in the same breath...
I am interested in helping with the user interface (the easy part i admit!)
I will try to help with planning, not my strong point unfortunately!!!
I'm sure we won't use SOAP. (Maybe it was joke?)