Reply to thread

Message: <blockquote data-quote="Sm!rk" data-source="post: 422166" data-attributes="member: 6467">That was an off-topic aside to address your mention of speed concerns. If it matters then VB should be ignored flat out IMO. However, thats really beside the point the issue as I hear it is that you could write your app in COBOL, and it should be interoperable. (Thats not gonna happen of course, but firm guiding principles are ok, or wishful thinking anyway.)Any sort of sharing will break down if any person is allowed to withhold, or decide what they *want* to export for public consumption. This is what all the OS licenses attempt to prevent to some degree.What I am hearing and saying is more of a LGPL approach, what you seem to be proposing is RFC formats which are totally open and unowned. For instance TCP/IP is an open standard.For example I have a port number for a town generator, what commands do I send to it to get meaninful data from it? Is this defined per app, or generically for all apps obeying such and such rules?You also go on to say that if my app wants a generated town I would effectively launch your app, in that case any system basically equates to a shortcut on my desktop. And at that point tcp or dll it doesn't matter you might as well use export as a means to communication between apps. (ie export an XML data file describing a town, then my fancy diorama program loads and prints that said town out for your to later fold together)The only real advantage against doing it the export-way is that the interface will be nicer for the enduser. They'll load up my app, click a button to generate a town (which calls and uses your app, preferrably behind the scenes) then prints it out.Your town generation process could have also used someone elses random store and tavern/inn generator which in turn could have generated from someone elses random NPC or barmaid generator. If that whole trail of processing could be made with one click in my app it would be fantastic.*But* IMO the interface would suffer if it was anything but invisible to the user. Even if your program is the best interface ever designed, its no doubt different than mine, and any others you use will have the same effect. In the above example there was my app, your town generator, the tavern generator and the barmaid generator. I will generate one town with 3 inns and each inn has 2d4 barmaids, in the ideal I would merely seed those generators with some overall goal and then get little or no interaction with the generation process, it doesn't really matter to a diorama.There are some other issues (many) one being the communication medium between all these different apps, then there is the issue of building the trail (who said legos?), so instead of fancy pants barmaid generator, I want to hook it to simple old boring female name generator. I don't want a fully stat-ed barmaid, just a name. Who is controlling that lego building, and at what point is it done? Does every app have to include some standard lego building options for each piece of their trail or is this dealt with on the user end behind the scenes of the program logic. An example of the latter is Unix daemons or NT services, you can use any number of programs for your ftp server, but they all talk ftp so thats how that bit of magic works.And just as TCP needs some overhead of just establishing the communication you will for each protocol (ie PC Generator, Town Generator, Poisoned Wine Visual Appearance Generator.)</blockquote>

Verification