This is going to border on the suggestion of an entirely new project (or
three), but I thought it was a pretty sound idea. I'm aware that PjD has
already put in a lot of effort on his editor and the design I'm suggesting
here might run at odds with that. I'm not making light proposals, here,
and so it's recommended that you either completely ignore them or go
full-blast ahead, rewriting/reworking/abandoning what has already been
done. Ordinarily, I wouldn't be quite so brash to recommend someone toss
out good work. But I've got an idea...
You see, things started to come together in my mind when I was considering
various aspects of an offline editor that can synchronize data[1]:
* It must be able to edit unique attributes and perhaps entirely new
resources[2].
* It must be able to send data and receive data in a Mud-independent
form, such that there is no reliance upon any particular reliance upon
the Mud's internal data file format or storage mechanisms.
* It must be able to have an authorized communication protocol with the
Mud to fetch, send, update, and delete resources.
The first two considerations can be combined into a single requirement:
* The editor must be extensible.
It would seem to me that we do not need to invent anything to handle this,
at all. XML is already there and well-supported. The Mud could pack its
internal data to XML for shipping to the editor, and unpack XML data from
the editor into its internal format. Since XML is extensible, we've
addressed all of our concerns. The definition of the XML document
structure (i.e., an XML schema) tells the editor what can be edited and
what input is allowed (free-form, a list of options, etc.). This would
replace the .INI files PjD suggested. Parsers for XML already exist, as
well, meaning integration with CircleMUD and the editor is more or less
trivial. Using XML also permits implementation of the editor ontop of,
say, Mozilla or Netscape 6 or any other browser supporting these standards
(read: not IE -- Microsoft seems to be reluctant to funnel some of that
enormous development staff and power towards actually useful, meaningful
goals).
PjD suggested addressing the last consideration -- synchronization with
the Mud -- via a new (UDP/IP) port and a new protocol. I'm going to toss
out that idea completely. Certainly, layering it atop an ordinary TCP/IP
connection to the Mud is not a good idea. Requiring the Mud to have one
particular user interface for editing is the apogee of poor design. What
I think would be better is to use an existing protocol to support the
editor.
Wonder of wonders, someone earlier proposed integrating a small HTTP/1.0
server into CircleMUD. HTTP/1.0 provides us with everything we need from
the protocol:
* A method to authorize the user for security.
* A method to GET a resource or an attribute of a resource.
* A method to PUT a new/modified resource in its entirity.
* A method to POST changes to an existing resource.
* A method to DELETE an existing resource.
HTTP provides all of these things for us in a clear, easy-to-parse,
well-defined, and well-supported standard. It also would allow for a
simple HTML interface to the editor functionality if all-else fails. The
programmatic benefits here are mainly in elegance of design and clarity of
all involved communication protocols and formats. In a more practical
sense, we benefit by combination of two seemingly unrelated projects that
may require some man-power, the editor and an HTTP server. In this, PjD
is freed up to write the editor to support the standards that will be
implemented on the server-side of things. The editor is completely
independent of CircleMUD's internals. The HTTP server group does not need
to go out of their way to support the editing facilities. They all appear
as typical HTTP requests, with the URI's path indicating that it refers to
a particular resource for editing purposes. Both gain from cooperation.
What'dya think, sirs?
-dak
[1] On the issue of semantics--and I'm not going to say much here about it
because it's a stupid topic--PjD was not semantically incorrect in his
use of offline editor. The editor application is, indeed, offline and
operates primarily offline. The ability to synchronize through the
Internet does not an online editor make. Doesn't Word allow you to
save files to a remote location that may be over the Internet? Is
Word then an online word processor? No. Stop being silly.
[2] In this case, "resource" meaning mobile, room, item, or what-have-you.
The term is used in reference to URIs.
[3] http://www.w3.org/Protocols/
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT