> On 1/10/03, 5:34:39 PM, Tom Sawyer <transami / transami.net> wrote regarding
> Re: [slightly OT] Using Observer pattern in client/server architecture -
> how?:
> > i'm not 100% clear on what your trying to achieve. so i'm just throwing
out
> > some basic thoughts and i'm by no means an expert on network coding.
>
> Thanks for sticking with this :-).  I'll explain more clearly exactly
> what I am trying to do.  If anybody thinks this is too OT for the list,
> perhaps we can take it offline?

please keep it on the list, or cc me in on any offline conversations - I'm
definately interested.

> Server - A ruby program that manages a set of data (we'll call them
> "Things").
> Client - A FXRuby application that displays a screen monitoring a
> "Thing".
>
> Many client programs can be started, the client programs can be anywhere
> - so we may have 1 on the same machine as the server, 5 running on
> another machine on the LAN, and lots running somewhere on the Internet.
>
> Each client program can register its interest in a Thing.  If anyone
> decides to change the state of a Thing, then the clients that have
> registered an interest are notified by the server.
>
> That's basically all I want to achieve.  As you say, I could make each
> Client a socket server in its own right, but I shouldn't need to (imho).
> If the server holds open the connection, then it can just send packets
> down it as the "thing" changes.
>
> I know that I can achieve this with a custom protocol - I just wonder
> whether there are open standards for achieving this - without having to
> make each client a server in its own right?

Firstly, I dont know whats available in Ruby, but coming from Java, what
you're after is something like JMS (Java Message Service) - not sure if
there's anything like that available in Ruby.

I think you mentioned SOAP initially - I read something a while back - a MS
recommendation called SOAP-MP (message protocol) or something, which would
be the sort of thing you wanted to acheive.  Essentially it provided for a
return message path with a soap request, and was a bunch of soap headers
that were included with the initial soap request.  It would then be up to
the SOAP implementation to provide the return path, as you suggest, via a
persistent HTTP connection.

Issues I'd see with the SOAP (or any HTTP approach) are:
    1. Defining the callback API for the client (pretty straight forward)
    2. Defining an API for the client to inform the server that updates are
no longer required (and hence close the HTTP connection)

Anyway, not sure I've really added anything here, but I'm interested in
following this, and seeing how these problems are solved in Ruby.

cheers
dim