A standard RPG gaming API

[Mynex]

XML standardization

Guys,

Overall, I like this concept, and it's actually something we've (the PCGen Core Team) has been aiming for and getting there slowly. Settling down PCGen, squishing bugs, making it faster, etc, have all taken top priority of late, but there is an additional PCGen group most don't know about... the PCGen XML group on the yahoo boards..

http://groups.yahoo.com/group/pcgen-xml/

They've pretty much settled most of the questions raised here, it's headed by Keith Davies, and I would expect to start seeing the XML conversion of the data files to take place sometime in the next few months.

The SCHEMA they are/have developed is fairly extensive and open ended, so the wierd things that publishers do to material won't be an issue, it will be easily modifiable for new things we haven't already taken into account as well (at least that's the plan).

I am pretty familiar with XML, but my time is devoted to several other aspects of PCGen (as well as RL), but I'll try to answer what questions I can if need be here.

DMTodd - Have you been importing/exporting pcg files (character save files for the rest of you. ) of the latest format? It's a lot cleaner and easier to read/manipulate now.

TownGen - When are you going to get it to start saving stuff man! I LOVE the proggie and can't wait till it's more than a pretty interface.

Klintus - Java may be slow, but the benefit it that's it is cross platform, which is one of the main reasons PCGen is coded in it. Support for Mac/*nix users is a good thing, especially considering that while M$ might be the deFacto standard of OS's in the US, it's not the case in many other parts of the world, and there are gamers the world over, so supporting them is a good thing.

 

[Fast Learner]

It seems to me that we should put a proprietary wrapper around the XML data that would be unique to our imprelmentation of it. That way, only someone who has written a program to the RPG-API can even get their XML data to the parser. That would be an extra level of security.

I don't understand why this would be a good idea, and can only see downsides at this point. What would we be protecting ourselves from?

XML is starting to make me kinda nervous though. Can a tag be imbedded in XML that causes the parser to run some code? If so, then a malacious person could possibly get into your computer via an imbedded XML tag (something like putting a VBscript into an HTML email which is run automatically by Outlook to spread a virus). So if we are going to use off the shelf parsers for the XML stream, we need to be CERTAIN that things don't get out of hand. Does anyone here know about this?

No, it's not possible in any generic way. It's certainly possible that you might write some code yourself that did this, so -- as any time you're writing code that imports outside data -- you certainly would want to watch yourself. There's absolutely nothing in any of the XML parsers that I've seen (including Microsoft's) that can cause any code to execute.

Anyway, back to the API discussion, how would a person make a SOAP function call in VB? Is there a SOAP activeX control, or is it a dll call? Where can I get this functionality and add it into my VB program? What about VC++. If it's only a Java library for XML then it doesn't do us any good. Is it usable on a Mac? What about Linux? What if I wanted to write a Win32 console application?

Here's a good article on VB and SOAP:
http://www.perfectxml.com/articles/WebSvc/vbsoap.asp

SOAP is a completely open specification. There's definitely plenty of SOAP code out there for the Mac and *nix.

 

[Klintus Fang]

Klintus, I'm not really sure what you are suggesting with the libraries thing. Do you mean distribute source code? I doubt any commerical applications would ever distribute their source code. I don't plan to distribute the source to my town generator. It's written in VB. The source wouldn't do anyone any good on a Mac or a Linux box anyway. Anything that involves distributing source code isn't going to work.

All you have to distribute is the compiled dll/so file and an appropriate header file that defines the api. You don't have to distribute the source code. Your town generator, for example, could theoretically, easily be compiled into a DLL and then called by another program. The fact that it doesn't work that way is the main reason I don't use it, BTW. Nothing the program does actually depends on the gui. There's no reason it couldn't be written to accept inputs from another program directly via some api and then have it return a pointer to a data structure that contains all the information about the town. THAT is what I consider to be what determines the degree of "interoperability".

Distributing libraries is quite easy to do across multiple platforms. Good C code will transport pretty smoothly back and forth between Windows and Linux (don't have much experience with Mac) so long as it doesn't have any GUI interfaces in it but instead makes use only of standard system calls that are available on all OS's. Sure GUI's are going to be problematic unless you write your code in Java. But that is true independent of whether or not you use TCP/IP as the communication interface. I don't see how TCP/IP is going to solve the cross platform problem at all. The code itself still has to be able to run on multiple platforms, in which case it has to be compiled separately on all supported platforms, in which case there's no reason it can't be designed from the beginning to be a dll instead rather than an independent application.

The issue of skirting license agreements with distributed computing is exactly one of the reasons I like it so much. I can write my program without including any OGC in it, but still have access to that material by using someone else's program that does use OGC material. Plus, if there are only certain things that can be done with OGC material in a program, if they expose the results of their program to others, then the programs that don't have any OGC in them, but merely import a finished character for example, can do anything they feel like with it. After all, how can they be bound to the OGL, if their program contains exactly ZERO OGC?

true. but that's also true if all the independent pieces are compiled as shared libraries as well.

 

[Klintus Fang]

Re: XML standardization

Klintus - Java may be slow, but the benefit it that's it is cross platform, which is one of the main reasons PCGen is coded in it. Support for Mac/*nix users is a good thing, especially considering that while M$ might be the deFacto standard of OS's in the US, it's not the case in many other parts of the world, and there are gamers the world over, so supporting them is a good thing.

You are right of course. But the bottom line for me is that I am not willing to trade performance for cross-platform support. If I were working such a project I would code all the core computation work in C/C++ and then compile it into a library (either shared or static, or both), distribute the api definitions and then have others write separate gui front ends for it on each of the platforms in question.

My personal feeling is that that isn't any harder to do then writing in Java.

 

[Klintus Fang]

No, it's not possible in any generic way. It's certainly possible that you might write some code yourself that did this, so -- as any time you're writing code that imports outside data -- you certainly would want to watch yourself. There's absolutely nothing in any of the XML parsers that I've seen (including Microsoft's) that can cause any code to execute.

I'm not an expert on this, but I too doubt that it's likely to be a concern in that respect. All a parser has to do is interpret text data and construct models of the data in memory. There's no reason it should ever need to do anything more than that. So it shouldn't be any threat at all.

A parser should only translate data from one format to another. It shouldn't be taking any actions (i.e. running scripts or binaries) as a result of what it sees in the text it is parsing. That is the job of the program that plugs into and uses the parser.

 

[Sm!rk]

towngen, I'm not understanding your worries about speed when then faced with the reality that you are planning to do your coding with VB.

TCP/IP while existing on all platforms does not mean its platform independent, far from it. Any code you write for communication will have to be rewritten for each platform, at least once for Windows and once for Unix. This is the same as would be needed for a standard approach using libraries, however very little of the code would have to be rewritten using a library, some notable differences exist in using files, but far less than with socket code.

For both of those there no doubt exist already written cross platform libraries (that is TCP/IP and files), its far more likely that a cross platform files library exists freely than TCP, but that is only a guess.

 

[Fast Learner]

towngen, I'm not understanding your worries about speed when then faced with the reality that you are planning to do your coding with VB.

Please. Compiled VB (not to pseudo-code, but to machine code) runs very fast, many, many times faster than Java. It's the next best thing to C/C++ for speed and (generally, depending on the programmer) kicks butt in development time.

 

[MythosaAkira]

Re: Re: Re: A standard RPG gaming API

Mythosa, I agree that the API shouldn't start out too big. But it can be expanded on as we go. The TCP/IP idea is one so that the identical standard will apply for all platforms. Personally, I'd rather just say do it all via the clipboard, or something trivial like that. But TCP/IP also allows the ideas of distributed processing.

This is a little OT at this point, but I wanted to point it out anyway:

Developers: Never touch the clipboard! The clipboard is there for the users - not your program (unless, of course, you have something like "cut" or "copy").

There is little that is more frustrating when something tries to take control of a standard feature away from the user (using Javascript to keep the "Back" button from leaving your Web page falls into this category as well). Frustrate the people using your program, and after awhile, you won't have people using your program.

 

[Davin]

Re: Re: Good idea

If it never goes outside my machine that kind of defeats the purpose of using TCP/IP to begin with, doesn't it?

Nope - TCP/IP talks to multiple programs on the same machine just great. It has the advantage of being able to talk outside the machine as well. And by outside the machine, that can also mean talking to a second machine on your LAN, both behind your firewall.

 

[Davin]

Well, I've looked into XML a little more and it does seem like I don't have to worry about parsing the XML text. I can just get an activeX control to do it for me. I assume that a similiar prepackaged block of code exists for java as well. So VB, VC++, and Java as have relatively easy access to XML parsers.

Yes, MS has an XML parser. Does Mac & *nix? Are they the same as MS's? Are they usable from the same languages?

And MS's parser has only gotten good enough to use reliably in recent versions. What if some user's machine has an old copy of it, or no copy of it. Would every person's application be responsible for making sure it's up-to-date? What if future backward-compatibility problems arose?

Don't get me wrong - I think XML is great for this sort of thing. Just don't ignore the hidden problem areas that can bite you way down the line.