Sounds like a very inconvenient interface.
I don't know of a tool that can help you develop a client for a raw socket protocol. I think you'll just have to write a socket client that listens for packets.

You might suggest to the service provider that they upgrade the event system to RSS.

Anne

On 11/12/05, Steve Cohen <[EMAIL PROTECTED]> wrote:
I think this may be the wrong list to post this on, but I am hoping that
someone will see this and be able to direct me at the right place.

I am charged with developing an interface to a system with the following
characteristics:

There is an XML-RPC interface with which one can exchange synchronous
messages via XML-RPC.  I know this is not the same as SOAP or Web
Services but it it close.  I know there is an Apache XML-RPC project
that provides the tools that could handle this, but I am not directing
this to their mailing list because I find it doesn't get much traffic.
Anyway, this is not my question but a mere preliminary to it.

As an adjunct to this synchronous XML-RPC service, this system also
provides for an "event channel" to which a logged on user may
subscribe.  The XML-RPC response to the initial logOn request provides a
host and a port number back to the requestor.  The requestor can, with
this information register for the event service and open a TCP/IP socket
connection to that host and port.

From that point on, various xml-coded event messages will be sent back
along the event-channel to the subscriber.  The xml in these messages is
similar to what one might receive via xml-rpc, but it's not coming in an
HTTP wrapper.  It's just random defined bits of XML coming at
asynchronous intervals.

I may be dense here, but what kind of client must monitor this event
channel in order to receive the events?  The P in HTTP defines a
protocol that presumably includes logic that delimits the beginning and
end of HTTP packets so that the reciever knows when to begin actual
processing.  This is what is used by systems such as XML-RPC and SOAP.
But this service does not run over HTTP.  It runs over TCP/IP.  Is there
a tool available that handles the "packetizing" of such a packet without
forcing me to write a tool that watches the socket byte for byte and
determines when a message has been wholly retrieved before submitting it
for processing?

Reply via email to