Reply to thread

Message: <blockquote data-quote="towngen" data-source="post: 417626" data-attributes="member: 1528">Re: Re: A standard RPG gaming APIMythosa, 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.As for the comment that you can't have multiple connections to a single TCP/IP port, actually you can.  A single winsock object can only have 1 connection, but nothing prevents you from using 2 winsock objects on the same port.  How you do think a web server allows more than one person to connect at the same time all on port 80?  The web server just creates a new instance of the winsock object and allows a new connection.Ok, in order to start defining data formats as is suggested by several, we need to know if XML is the way to go or not.  What does using XML give us?  Personally, I would rather just define it ourselves, but I wanted to hear the arguements for and agains XML first.  Why would it be better than just defining a string format ourselves?Suppose we just created something like this:OpenSession(<calling program name>,[user name],[password])CloseSession(<calling program name>)CreateReturnObj(<unique id key>,<object type>,[attribute list])CreateEditReturnObj(<unique id key>,<object type>,[attribute list])ReturnedObject(<unique id key from the create request>,[error codes],[object string itself])RunCommand(<unique id key>,<command>)KeepAliveReq(<unique id key>)KeepAliveAns(<unique id key>,[error codes])UnrecognizedCommandAs per standard syntax, <key> mean that the key is mandatory.  And [key] means that it's optional.  Obviously the symbols <, >, [, and ] and not included when really coding.Open and close session are self explanatory.The 2 create object calls would each require 2 arguments, and have a third argmument as options.  CreateReturnObj would be a command to just create it and return immediately, without any poping of the user interface.  CreateEditReturnObj would tell the program that it is allowed to open it's user interface for interaction before returning the resulting object.  The unique id's would simply be a serial number so that if multiple requests are being processed at once, it can identify which request it's answering.ReturnedObject would be the format of the message returning the object (or an error).  The general command would be for other stuff, not when you are asking for an answer, but just want the program to do something.The keep alives would be for a program to query and see if they are still working on the specified request or not.  It would have to be answered quickly.The unrecognized command would be the standard answer for anything that didn't fit into the above categories (or later defined terms).The list of objects would simply have to be defined and agreed upon ahead of time.  Same for the error codes, commands, and the formats of the objects themselves.Anyway, this is just something I came up with in the last 5 minutes.  Parsing and handling something like this would be very easy.  The TCP/IP connection is very easy (just read about winsock if you're using programming in Windows and not familiar with TCP/IP, it's not difficult).  We would just have to agree on the list of objects, commands, error codes, and formats of each supported object.  As we agree, we add them in to the standard.  Everything need not be supported right away, so we can start with a handful of most wanted objects (probably characters, monsters, and treasure), then expand as time goes on.But like I said, this is just a quick "off-the-cuff" stab at a comm spec that wouldn't use XML.  I don't know much about XML, but lots of people talk about it like it's great, so I figured I would hear the pros/cons about it.  Anyone want to give and pros/cons about XML?[can't spell, sorry hehe]</blockquote>

Verification