Well, I'm at it again, starting yet another version of soup bot. My intention is simple - to create a service that specifically connects to battlenet and relays any incomming events to to a specified port on the local machine. The third party gui will simply wait for data to arrive on that port, and handle it appropriately. Essentially, the service will be the client and handle all the core battlenet processing. The gui will be an optional, at times, means of communicating with the running service.

Right now, I'm brainstorming, and was thinking about making the service 'blast' out udp data to a certain port on the local host so that there is no connecting involved and so that the data is always being constantly 'blasted'. This way, with or without a running 3rd party gui, all the data will be relayed and available for handling by any 3rd party gui. The only problem with this is that I will not be able to make use of this service from a different machine. I'm not sure if this is a bad thing, or a good thing, but for the sake of asking - would it be better to make communication between these two interfaces use  TCP, and require an active connection? Does UDP sound like it'd be a quality method? What does Skywing's BinaryChat use? (I think BinaryChat does something similar to this.)

Are there possibly any other crazy ways that I don't even know of? I mean, could my ideas be the granny panties way, and there exists some lace-thong way to do this? I dunno, this is why I'm asking.

I have no clue how JavaOp (the first one) does it, but it has a remote interface.  I suggest you take a look at that.

[quote author=rabbit link=topic=15364.msg155547#msg155547 date=1152490329]
I have no clue how JavaOp (the first one) does it, but it has a remote interface.  I suggest you take a look at that.
[/quote]I believe JavaOp 1 uses RMI (Java's Remote Method Invocation) which essentially creates a transparent proxy between the server and client.  .NET has something similar in Remoting.

It's kind of cool, but I've found that, in order to make those protocols as generalizable as they need to be for those kinds of scenarios, they get to be too bulky.