A standard RPG gaming API

[smetzger]

Luke - If a BCB app used the Fastnet controls would another compiler be able to 'talk' to it via TCP/IP ?

TwinRose - You mentioned BCB 6.0. Are you using the VCL or are you still using OWL ?

No matter if you are using the TCP/IP method or the DLL method I believe that the Master program will need to have intimate knowledge of the Slave program and thus would most likely only interface with a select few Slave programs that the coder of the Master program has specifically chosen. There are ways around this by using App Servers and/or J2EE, however, these are really only viable solutions in an enterprise environment. Because of this restriction I don't think that cross-platform is necessarily a concern. Besides there are so few applications available or in development for non-windows OSs.

Luke is correct about the cross platform limitations of DLLs. The only way is to make your interface cdecl and make sure you don't have any functions with variable numbers of parameters. A must more robust interface is via OLE Automation, however, I doubt Java can talk to it.

Practically speaking the only way this will become a reality is if some programmers start providing an interface into their programs, either via TCP/IP or DLL or OLE Automation. So my suggestion is to use your favorite method to expose as much of your program to other programs and then to petition other developers to expose some of their code.

 

[Twin Rose]

Luke - If a BCB app used the Fastnet controls would another compiler be able to 'talk' to it via TCP/IP ?

TwinRose - You mentioned BCB 6.0. Are you using the VCL or are you still using OWL ?

Luke is correct about the cross platform limitations of DLLs. The only way is to make your interface cdecl and make sure you don't have any functions with variable numbers of parameters. A must more robust interface is via OLE Automation, however, I doubt Java can talk to it.

I'm in the process of making the switch to BCB 6.0 now. It will require some work, but the end result is desirable to me.

CS uses OLE to some extent now, but not in a way that I'm satisfied with. If it comes down to it, I'll make the SDK I mentioned 'open source' much like jpeglib or another cross-platform library.

 

[dvvega]

An idea to "solve" the mentioned problems with using TCP/IP ...

when a program executes an external program call,

1) checks to see if that program is on the local machine
2a) if it does not find the program, (if configured to do so) downloads to the local machine

2b) if it found the program on the local machine (if configured to do so) it checks version numbers and updates the local machine if required

3) it executes the call to the external program (now on local machine OR still on a server)

Now this way, when you make searches for programs that answer your request, you scan your localhost (127.0.0.1) first and then scan the outside world if you don't find it.

What does this mean in the end?
1) updates are regularly obtained as required (and if you want to store locally)
2) if you don't want local versions you can stick with the TCP/IP to external servers and hope they're up
3) you can use this API system and it's programs on a laptop at the gaming table away from an internet connection

 

[towngen]

Between all the different ideas here on this thread I'm not exactly sure where we stand right now. I kinda like smetzger's idea of: just do something. But I'd hate to start out in the wrong direction and have to redo everything.

Perhaps I/we ought to work on a subset of the problem first, then expand it once something concrete actually exists. Some people watching this discussion are probably beginning to think this will amount to nothing but wishful thinking and extremely excellent theoretical vaporware.

With my current school schedule (why did I decide to take 10 hours this semester?) and the demands of my job, it's going to take me some time just to get started.

Since I don't know beans about Mac and Linux, the only thing that I personally can do is start implementing a windows version of the session layer that will sit on top of TCP/IP. This layer will not know what kind of objects are being requested or sent. It will simply establish and validate connections, and provide a platform specific (windows) interface for it. Once a specific protocol is worked out for windows, then it could be implemented for other platforms.

I guess XML is the idea solution for the presentation layer, even if TCP/IP turns out to be less than perfect for the session layer. If someone wants to start designing this layer, you could do so even before anything is finished with the session layer. You can assume that you will receive an ASCII text string containing something from another application. And you can ignore (for now anyway) issues of how to "dial up" another application (either local or remote). The session layer will deal with that. This layer will have to figure out what the message is and what to do with it. Is it the answer to a previous request, or is it a request and if so a request for what? This layer will also have to package up local data (requests or answers to requests) for transmission via the session layer.

Can someone work out the basics for the presentation layer for handling a request and answer to a relatively simple object? Once a basic version of a presentation layer is developed, it could be tested with the session layer in a simple test application. Once it's working, then the two layers could be alpha released so other people can add other objects into the definition. Once that is tested some, then we can release a first version of this thing.

If things turn out poorly for TCP/IP, the perhaps we can change the form of the session layer to some other methodology. The same goes for XML in the presentation layer. Also, we don't have to implement every possible function in the session layer to start with. We can start with a simple local only connection, then build from there.

Does this sound like a halfway reasonable plan to start actually accomplishing something? Anyone wish to suggest a better plan of action? Also, there is no reason that we can't start down 2 paths right now, and decide after there is something concrete which to choose to go with. Or is there a reason why we can't do that? Any thoughts? Better ideas? Do multiple groups want to work on this in parallel to improve the chances we will actually finish this? Do we want to try multiple ideas and test how they perform?

 

[Klintus Fang]

I'm interested in seeing if there is some data format that can be converged upon. There are so many possibilities that that task seems gigantic. I'm not interested in taking a lead on that though. It makes sense for someone who actually has a program with some content to share to lead that sort of effort.

 

[Klintus Fang]

Luke: you are right about different compiler's having difficulty reading each other's libraries. I've had quite a number of problems with this on Linux as we use two different Linux compilers at work.

On windows though, I must admit I haven't used any thing other than MS's compiler in a long time now. But I just have been doing a little research on the web regarding this and it appears that getting Borland to read MSVC DLL's can be done but it looks quite painful.

In any case, it wouldn't be hard to simply request everyone wrap c-stubs around their c++ code if a group of people using different compilers choose to go the library route.

 

[Klintus Fang]

but it all does point at an interesting thought. a tcp/ip solution might be a work-around for language or compiler issues, though I think there are better solutions if that's the only problem. I still don't think it helps cross-platform issues. the only way I see to do that is to use languages that compile on multiple os's and rip out the os-specific code; likely the guis. Unless the language you are using is Java, in which case things are usually portable (but I really do get annoyed when I have to install company C's x-y-z version of Java just to use some tool that I just downloaded).


my personal coding style has always been to write most everything with text interfaces using stdin and stdout and/or file i/o so I can compile them anywhere and if the thing really needs a gui to be fully functionally later I worry about that at the end. devoloping from the outset with everything meshed into the gui code really leaves you in a pickle if you want any sort of cross-platform ability. but that is neither here nor there. just a suggestion about how to be more multiple os compliant without relying on java.

 

[Fast Learner]

An idea to "solve" the mentioned problems with using TCP/IP ...

when a program executes an external program call,

1) checks to see if that program is on the local machine
2a) if it does not find the program, (if configured to do so) downloads to the local machine

2b) if it found the program on the local machine (if configured to do so) it checks version numbers and updates the local machine if required

3) it executes the call to the external program (now on local machine OR still on a server)

Now this way, when you make searches for programs that answer your request, you scan your localhost (127.0.0.1) first and then scan the outside world if you don't find it.

What does this mean in the end?
1) updates are regularly obtained as required (and if you want to store locally)
2) if you don't want local versions you can stick with the TCP/IP to external servers and hope they're up
3) you can use this API system and it's programs on a laptop at the gaming table away from an internet connection

That's certainly what I meant. (Well, not auto-downloading applications necessarily, but doing so with the user's permission.) The app/port/dtd/etc. list would only be updated if a connection was available, not every time you run an app.

 

[Luke]

Luke - If a BCB app used the Fastnet controls would another compiler be able to 'talk' to it via TCP/IP ?

Sure Scott. TCP/IP is a pretty low level way of communicating, and there are about three different class wrappers available that will work from BCB.
Basically, once you've made a connection to another machine (whatever compiler was used to create the app, or even whatever operating system its on), you can simply read and write blocks of bytes to one another.
Reading and writing text makes it pretty easy to find any issues, and the main thing to watch out for is that there's no guarantee that the blocks of written data arrive in the same block structure at the other end. This generally applies to large byte blocks, that could arrive as multiple packets at the receiving end ("always" arrive, and in order, though).

To give you an idea of how easy and universal tcp/ip communications is, I'll use an example very relevant to this thread.
I initially used it to interrogate the on-line Jamis Buck NPC Generator in RPM. I essentially made a tcp/ip connection to the web server Jamis was using, and sent a text string (HTTP GET command) that would be expected from a browser. The result read back was a format expected by a browser (HTML page), and I just extracted the relevant data to import creatures into RPM.

Jamis urged me to use his source code, but it didn't quite feel right about that, so I eventually just included his EXE with RPM, and support copy-and-paste to import from his generator. People loved it, because, although the copy-and-paste was slightly less automated, it did work well off-line.
Also, I had to figure out how to tunnel out from behind firewalls, and create a "proxy server" configuration for RPM (much as you set up in your browser). This is an additional confusing pain for people. Also, the generator server was (very) occassionalyy off-line, and had an upgrade once, which meant I had to update the HTML extraction.

All those sorts of things point to issues that the on-line tcp/ip concept will be faced with. Klintus' idea for accepting code modules onto your machine sounds cleaner from that perspective (you can control what you get and when you upgrade), but also has issues, which I've already mentioned.

 

[dvvega]

Fast Learner: that's what I meant when I said "if configured to do so". I meant that to represent a user configuration option.

And doing the scan all the time is not a problem since if there is no connection it will not succeed at a scan except for localhost.