dooberwah has asked for the wisdom of the Perl Monks concerning the following question:

Hello everyone,
I'm trying to write a chat program (daemon and client) using the SOAP::Lite module. My current understanding of SOAP::Lite is that the client has to run a function on the server, and that function returns a value. While I was thinking about it I thought that what I really wanted was for my chat server to send all new messages to all the clients. I don't know if my idea is even possible, and I'm sure it's not the most efficient design.

I currently don't have any code, because I've been stuck up on these fundemental design problems. Please respond before I hurt myself by hitting my head on the wall. ;-)

-Ben Jacobs (dooberwah)
"one thing i can tell you is you got to be free"

Replies are listed 'Best First'.
Re: SOAP::Lite Chat
by Foo::Bar (Acolyte) on Dec 25, 2001 at 02:57 UTC
    SOAP is just a way to transfer information. Your server con not "auto-update" all clients when a new message arrives because the clients need to request the information from the server, not the other way around. I think the only way to do what you want is to either have the clients poll the server on a regualr basis, or to blur the line between client and server. The chat server would contain soap server code as well as soap client code. same goes for the chat clients. The server could then call an update method on the chat client (soap server) for each chat client connected. SOAP is not going to help you sort out what clients are connected though, as I said, it is just a way to transport information.
[reply]
Re: SOAP::Lite Chat
by jepri (Parson) on Dec 25, 2001 at 03:45 UTC
    The other replies are good, so I'll just toss in the final piece of info... SOAP uses HTTP and deliberately keeps it connectionless. This allows requests to be bounced through proxies and other tricks. This is exactly what you don't want but the solution by AM covers most situations, unless your users are behind proxies (very likely, in this day and age).

    The SOAP mailing list was full of people complaining ( last year some time) about the lack of what you wanted, but looking at the design goals your desired feature had to be sacrificed. Perhaps you could look at other approaches to lightening the load on the server - a "are there new messages for me?" function combined with an exponential delay when there are no messages might be a start.

    Keep in mind that even if you write your own protocol (not too hard if you put it in a module and abstract it properly) a lot of firewalls will swat the connection. HTTP is about the only thing you can rely on getting through.

    That's why I always use the web-page chat client for PM when I'm at work.

    ____________________
    Jeremy
    I didn't believe in evil until I dated it.

[reply]
      Revising my earlier comments ... if your going to port this to a game it really depends on the game. A multi-user RPG probably would not be best with SOAP because of the (possible) Lag-time involved in the passing of messages (you wouldn't want to still be trying kill the orc someone else killed 3 rounds ago) ... then again this is exactly what someone was talking about on the Axis.apache.org website so who am I to talk?
[reply]
Re: SOAP::Lite Chat
by Anonymous Monk on Dec 25, 2001 at 02:54 UTC
    I'm currently working with SOAP::Lite but I don't happen to have that code (the provided Chat.pl file) in front of me at the moment. From what I understand however design wise you could build a single Application that is both a "server" and a "client". It would work like this. User A and User B both run the application. A's app exposes a postMessage() method on port 80 (via SOAP) and Client B's app access this method. On the other end B's app does exactly the same thing, while A access the Method. This should work in general design issues (and I think most of the code is on the www.soaplite.com site) but standard disclaimers apply.
[reply]
      I think this would work pretty well for a chat application (I think this is bassically how ytalk works). My main problem with it is that I hope to later use relitivly the same code for a multiplayer game (Communications Between a Game Server and Web Front End). This chat program is just my way of learning how to use the SOAP::Lite module.

      -Ben Jacobs (dooberwah)
      "one thing i can tell you is you got to be free"

[reply]
Re: SOAP::Lite Chat
by dooberwah (Pilgrim) on Dec 24, 2001 at 23:54 UTC
    Apparantly I'm not allowed to edit my own SoPW post. Anyway, I have already read through the chat.pl code that comes with the SOAP::Lite sources. I havn't been able to make it run it yet, so I don't know exactly how it works from a user's point of view. From what I understand it pauses while a user is typing in what they want to say.

    -Ben Jacobs (dooberwah)
    "one thing i can tell you is you got to be free"

[reply]
Re: SOAP::Lite Chat
by Steve_p (Priest) on Dec 25, 2001 at 10:06 UTC
    Setting up a chat so that each client talks with every other client would be difficult (read nearly impossible). Think about perlmonks.org. During the day, there can be over 60 people logged into the site plus any number of people visiting the site from all over the world. Now imagine if someone entered something in the chatterbox. How would my browser know what browsers to send the message to?

    While this is a somewhat convoluted example, how would the various clients know what other clients are out there without connecting to some kind of server.
[reply]

Back to Seekers of Perl Wisdom