I don't know XML programming, so it's a little tough to comment on some of the advanced techniques you are talking about.
I've looked at the XML conversion of my file that Nick mailed me, and for the most part, it appears easy to read, and I hope it won't be too difficult to learn once I try interacting with it directly.
...In the meantime, I was wondering about the client interface. You mention using "include" directives in the code, but what I think I would like to see is the ability to declare include files via the setup interface. The other thing you have not mentioned, is multiple script files.
Now, here is something I would like to do:
Write a script file "plugin" for use at a particular mud, or type of mud. Include the triggers, aliases, timers, variables for use at that mud.
Under this XML implementation, I would expect to share 2 files to accomplish this task:
Script Project.XML
Script Project.VBS
Optimally, for the user to include my plugin, they would go to a screen in their setup/preferences, and (perhaps):
Click: Add Plugin
Enter directory for XML file.
That's it! Done. The novice user would not need to dictate what script file(s) to use, or where they are stored... The XML file should be able to handle that. They would not need to run an "/install" (at least not to install the triggers/aliases). They would not need to edit their main script file to modify (the current workaround) code to "include" the script "plugin".
Here are some things I think Nick would have to consider in programming the interface:
Collisions (as mentioned already).
Multiple script files.
Script file routine names colliding.
Script file global (not mushclient) variables colliding.
Variable scripting languages, among multiple script "plugins".
Trigger/Alias/Timer/Variable interface editing. Which XML file are they editing via interface? Indeed, ANY setup options, which XML file are they editing?
Now... In the context of Microsoft Windows, you get multiple programs running "at the same time", each as thier own "virtual machine". Of course, they aren't really multitasking, they just take turns using the processor very quickly.
In the context of Mushclient, I think a similar approach might be useful. A sort of "virtual XML machines", all sharing the output/input windows, and client interface (kind of like Windows does). The priority would likely be a bottom-up approach:
XML plugin A
XML plugin B
XML Character file
XML World file
Any output from the mud would be processed by the last XML file, then the next up, then the next up, etc... Any text from the command line would be processed in the same manner.
Since each XML file would run in a "virtual machine", collisions would not be as significant. You could have the same mushclient variable in BOTH plugin A and B. You could have an alias "scripthelp" in BOTH plugin A and B. In this example, first plugin B would process the alias (and do whatever), then plugin A would ALSO process the alias (and do whatever). Of course, trigger collisions would be handled the same way.
One XML file could use VBS scripting, a different XML file might call a pearlscript.
The only collisions left to handle would be certain settings that really shouldn't be duplicated, like connection info, number of lines to keep in scrollback buffer, etc...
To edit any other settings via an interface, the user would have to dictate which XML file they would like to edit first.
All this came off the top of my head, hope it makes sense.
:) |