Reply to thread

Message: <blockquote data-quote="towngen" data-source="post: 419216" data-attributes="member: 1528">My biggest concern with the whole XML thing really just stems from my lack of knowledge about it.  If everyone is reasonably sure there isn't any way to make an off the shelf XML parser do something dangerous, then yes it sounds great.  So the message is, don't worry about XML opening some security backdoor.  Cool.  That was something I just didn't know enough to answer.I agree that speed was a big issue in the old days when I first started with VB.  But ever since it started actually compiling the code, it runs really fast now.  It's not quite as effecient as C/C++ perhaps, but for the difference in development time and on a even somewhat modern CPU, it's a quite handy development environment.  But anyway, the merits of VB isn't really the point here.I think the speed of the communications is really important.  If the speed isn't really fast, it limits what can be done with it.  Suppose, someone creates a database of spells.  Then another person wishes to link to it to create spellbooks randomly.  There could potentially be quite a lot of queries back and forth for a single spellbook.  Then suppose that spellbook is created remotely by yet another program that created a wizard.  And the wizard is created because of a request by yet another program which is creating an NPC encounter.  People are going to bitch at the NPC encounter program for being sluggish and slow.  They might be irritated even with the speed of a TCP/IP connection.  Crunching the hard drive for 30 seconds to create an NPC encounter party would be unacceptable for a lot of people.I was under the impression that DDE used the clipboard, which is what I was meaning, but again that isn't very cross platform so it's pretty much out.  Again, the best implementation for me would be to just create an ActiveX DLL to handle it, but since I don't think that will work on Linux and Macs, it is too limiting.Perhaps, I was misunderstanding the suggestion to use the shared libraries.  Are you suggesting that the standard we create actually consist of actual code blocks, kindof a glue logic, that programmers can use to link to each other's code?  I never really considered doing that.  I was thinking just writing a document that described implementing a standard protocol.  Then each programmer that wishes to use the protocol would include their own code to implement it.  I guess there is fundamentally nothing wrong with this idea, but it would have to come after the API document was written.  And it would then become the end programmers choice whether to use a release library (if one exists for their platform) or write their own.  But it's a good idea to package the code up for people so they can implement it faster themselves, sorta like a set of working example code they can cut&paste into their program.Or are you not meaning to put just the comm spec in a library, but our whole programs?  Hmmm.  Somehow, I'm just not seeing this as a practical solution.  Perhaps, if you could explain this better.  Many applications require a user interface to operate, so reducing them to a library of platform independent function calls might be difficult to impossible.  Or am I misunderstanding you here?I could have sworn there was an option in winsock to non-exclusively open the port, but perhaps I'm mistaken.  The last application I wrote with TCP/IP was a client/server thing about 2 years ago in MFC, so it wouldn't suprise me if I recall wrongly.  Whatever ... the point is, whether you have an initial connection port and then you hand off to a different port or not, it is not really that big a deal.  If the API required each program to enter into a listen mode for a remote connection, it's not a big deal to me.As far as the wrapper thing goes on XML, I was only bringing this up because it seemed the XML data might be a security problem.  But since it apparently isn't, forget the wrapper idea.Also, Klintus, my guess is the real reason you haven't used my town generator is that the beta version I released a while back was merely the GUI.  It didn't actually create anything yet.  <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" />  And yes, the GUI isn't entirely necessary if you want a COMPLETELY random town.  But most people know whether they want a hamlet of 30 people, or a sprawling metropolis of 130,000.  So, you gotta direct the GUI a little bit at least.  Unless the party got a weird curse that teleported them to a random town somewhere in the universe, you're gonna have a small idea of what you want the town to be like.  And even in that weird case, I doubt many DM's would truly allow their campaign to be driven by a random number generator in VB.  Even if I wrote about a thousand logic constraints on the results.So lets see, where are we?The consensus seems to be that XML is good.  Ok.  I guess I gotta read up on it some more.  Add one more thing to my list that is 80 miles long already ...  Unless we get some volunteers to start doing this, it could be quite a while until it's done if everyone is going to wait on me.Still a little debate on the TCP/IP thing.  Can people who favor using the file system, or using shared libraries support the reasoning for those sytems and their advantages and weaknesses.  This will allow everyone to compare them with TCP/IP communications more easily.Any commentary from other developers on whether they might include this in their applications once it's developed?  If so, what kind of functionality might you expose for others to call on?</blockquote>

Verification