For example, you have a Servlet that has access to a Map of XMPP clients (your own class -- a client with no GUI -- assembled out of Smack classes or similar). Each key in the Map is set as an HttpSession attribute. Now you have one XMPP client per HTTP user. The client is logged into your XMPP server within the local network -- it is collecting packets, or sending packets, on behalf of the browser user. When the browser user submits a form to send a message, the Servlet looks up the right XMPP client and tells it to send the message. When the browser user polls for updates, the Servlet outputs the current state for that user (any new messages, any new presence updates, any new roster modifications, etc.). Now you have a true messaging system that can support any XMPP client, not just a browser adaptation. Maybe in the future you'll be able to use Swing, or there will be some HTML browser that also has an XMPP plugin (it won't come from Microsoft). Not sure what the J2EE police (or a TCP expert) would say about keeping sockets open within the confines of a Servlet container.
I suppose Leon is thinking in terms of doing something directly for the HTML browser, and doing it quickly. I am thinking in terms of using a system built for messaging, and then adapting it for a browser if you must.
For your situation, I cannot say which is the right approach. You'll have to judge for yourself. I would do my homework.
Erik
Erik Weber wrote:
XMPP and HTTP are nothing alike. XMPP is a stateful protocol and HTTP is a stateless protocol. XMPP pushes out alerts actively while with HTTP you have to poll when doing messaging. XMPP is all XML (and extendable) in addition. If you are going to use XMPP (and you should, instead of hacking a messaging system -- particularly a presence-aware system -- out of HTTP, which is called the HYPERTEXT TRANSFER PROTOCOL for a good reason), just get Smack. The guy who wrote the book you bought is from Jive Software, and they are the ones who develop Smack. You can get something going in a day or two with it. This is going to give you all the standard XMPP queries (give me my buddy list, add a contact, remove a contact, add a group, switch groups, query server for the list of all users, send message, tell everyone I'm online, away from my desk, etc., etc.) plus all the XMPP parsing and packet handling/collecting. Plus it gives you active and passive notification (like I said, they need a tad bit of help in their multithreaded programming -- I may submit a contribution to their source but I need to see what they've done in 1.5 first). Also it has built-in support for custom messages (via the XMPP "x" packet) -- you can use these for programming "actions", or for switching your GUI based on custom message types.
I suggested Sockets, ServerSockets, Threads and XML handling because you'll need those if you want to implement your own XMPP client and/or server. A library like Smack (there are others, but it's the best one I evaluated) handles all this and gives you objects instead.
Forget HTTP.
Erik
Leon Rosenberg wrote:
If you have to embed it in your site, and in your site only, forget about
sockets, xml and other "complicated" staff.
3 actions (getmessage, sendmessage, checkmessage) 2 html pages, a bit
javascript (for reloads) and 5-10 classes on the business logic will be enough.
Don't make things unneccessary complicated :-)
Regards Leon
P.S. if you find that you need a more complicated solution in 6 month, you
still can develop it then. Develop now things you need now, don't look for tomorrow :-) (X.P.)
-----Ursprüngliche Nachricht-----
Von: Miquel Angel [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 5. Mai 2005 08:36
An: Struts Users Mailing List
Betreff: RE: [OT] Recommendation of Instant Messagging System
Erik, Leon and Jason, thank you very much for your answers.
I think we will develop our own system (we need a messaging system integrated with our system: our table of users, our forms, ...), but we have no experience with sockets, ServletSockets, Threats ... We are goog developing business software (data base access, transactions, reports, ...)
I found a book that seems a good point to start : Instant messaging in Java:
The Jabber protocols
We are looking for a system to start to work with it (we expect to find it in that book).
One important requirement is that this software must run on Internet not only in a Intranet.
Yours, Miquel Angel Seguí
-----Mensaje original-----
De: Erik Weber [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 04 de mayo de 2005 18:39
Para: Struts Users Mailing List
Asunto: Re: [OT] Recommendation of Instant Messagging System
I just finished putting together a system with a Swing client and combined services over XMPP and HTTP.
I think Leon's suggestion of doing your own is not bad, if you are good with Sockets, ServerSockets, XML APIs and Threads (find a good tutorial on building a chat system such as in the ubiquitous "Thinking in Java").
There is also JMS which gives you a low-level core. If you want something higher level, just get Smack from jivesoftware.com, which will give you an OO interface to Jabber (XMPP). Then get jabberd from jabber.org. jabberd 1.4 is small, written in C and gets the job done for what you are talking about, so I would start with that. They are working on the 2.0 "enterprise" version.
I will warn you that while Smack is a great library (you'll get classes such as "Chat", "Packet", "Message", "Presence", etc.), there are some pitfalls related to Threading to watch out for. I rewrote about a half dozen of the core classes. Fortunately, Smack operates with just two main disptach Threads so once you spend some time with the PacketReader and XMPPConnection classes, you'll figure it out. Apache license, too.
Erik
masegui wrote:
The requirements are these:
1. A user has a list of the other users in the system. He
can click a
button that initiates a conversation with the selected user.
The other
user can accept or not the conversation. If accepts, a "chat
room" is
opened and now then can have a conversation. The rooms only accept 2 people. We would like a user to be able to have several
conversations
it's normallyat a time, but each conversation only between 2 people.
Thanks in advance.
Miquel Angel Segui
<-----Original Message-----> From: Leon Rosenberg Sent: 4/5/2005 10:50:38 AM To: user@struts.apache.org Subject: Re: [OT] Recommendation of Instant Messagging System
if your only functionality is to allow users to send each other
messages
which are embedded in the site (html, or something, but no standalone-desktop solutions) forget about existing systems and implement it by yourself.
I have implemented dozens of such systems over the time,
----------about 100 locs, much less effort than an integration of an existing system is.
maybe you could tell us a bit more, about the requirements of the system, so we could give you more specific answer.
regards Leon
On Wed, 2005-05-04 at 08:13 +0200, Miquel Angel wrote:
We are developing an application (struts 1.1 + Tomcat 5.5 + Java
1.4). One
of the requirements is to implement an instant messaging system for
the
users of the site (the system should not be very complex). Do you
mind to
share your experience in using this system. We are looking for free
or non
free systems.
Thanks in advance.
Miquel Angel Segui
-----------------------------------------------------------
---------To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
