Reply to thread

Message: <blockquote data-quote="towngen" data-source="post: 420463" data-attributes="member: 1528">Sm!rk, I understand what you are saying, and I agree with some of it in theory.  But what you are talking about seems to be more on the theory side of an argument rather than a practical side of an argument.  There are a great many program that do "real work" which are written in VB.  The total efficiency of society is not my concern here.  The theoretical limits of effeciency as the numbers of users gets big compared to the number of programmers is completely missing my point.The reason I am interesting in a platform independent solution, and obviously I can't speak for the rest of you so this is just MY reason, is that I want to "reasonably maximize" the number of developers out there who are creating programs which can work with each other.  It is the number of developers creating programs that support the standard which is going to decide the standard's success or failure.DMFTodd, I am glad to hear that you ran into this exact issue of interprogram communication with your program.  I hope that fact helps solidify your support of SOME standard, even if it has nothing to do with what I am trying to motivate people to support.Davin, it wouldn't suprise me in the least that I am confusing a great many things here.  I just want to get everybody onboard and excited about a standard of interapplication communication for RPG programs.  Frankly, I could care less the final form of it.  As long as it works and doesn't add 6 months to my programs already too long development cycle.  I just wan't something to be created that everyone will actually start using eventually.Klintus, you are correct in your view that my town generator should be able to create a town as a function call without needing to interact with the user interface.  That being said, I don't plan to release a GUI'less program as a library to be included in other people's programs.  The program should support exporting it's functionality IN ADDITION TO having a GUI and running as a stand alone program.  So if you gotta open my program for the export stuff to work, that seems great to me.  If it opened automatically as a minimized application, that would be a convienence bonus, but not a necessity (IMO).  But I don't think I would want to allow my program to be invoked invisibly.  If the town is coming from my generator, but being presented in someone else's program, that's cool, but the user ought to be at least vaguely aware that the town was created by my program.  I'm sure other programmers would like to make sure users of the program know that their program is being used.As for the question of why is it listening to a TCP/IP port if it requires the GUI to function, because a particular program may export only SOME of it's functionality.  I might decide that I only want to enable the exporting of a town when the user is sitting at the summary screen.  Or, perhaps I don't have time to implement the full blown "function call" like interface, and will only export a town that was created via the user interface normally because that's all I had time to do.  I don't really know.  I'm just trying to come up with examples.  The issue is that I don't know what all people are going to want to export, or import, or why, or what the resources are for people writing these programs, etc...I do like the idea of creating a distributable library which contains the code of a simple implementation of this protocol.  Kinda like a RPG-API SDK, or something like that.  If we wrote one in VB, VC++, and Java it would probably cover 99% of all the developers out there.The idea of using a single dll that resides in the windows/system directory as a clearing house for communication is a good one.  I know so little about Macs & Linux that I don't even know if they utilize dlls the same way Windows does.  If I wrote a dll for Windows in ANSI C that didn't use any specific Win32 function calls, how difficult would it be to create a dll on the Mac & Linux platforms from that source code?  When 1 application calls a dll on a Mac, does it create a new virtual instance of that DLL in memory that only that application can touch?  Or can multiple applications all call the same instance of a dll.  In Windows 98, all Windows applications share the same virtual machine, but Windows 98 obviously has a different approach to it's architecture, so will such a method work on a Mac or on Linux?  Does anyone know how the separate application spaces in WinNT based platforms would affect such a clearing house dll?  I've never tried this on a NT box, so I don't know if the instances of the dll would be the same or not.  Anyway, if no one knows for certain about WinNT, I'll probably look into it some one of these days when I get more spare time.  But I'll need someone to help with figuring out the Linux & Mac versions of that question.  I don't even have access to a Mac, not that I'd know what to do with one anyway.  Boat anchor anyone?  jk  <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=":)" />I guess we need to resolve this single dll as a clearing house idea to see if it's feasible.  If it is, then that would definately be the easiest way to go by far.  After we go it up and running for the local machine only, we could potentially add in some distributed communications aspects to it later on.</blockquote>

Verification