Short: Use of XML in save_object()
From: Tom Jakubowski <tom@crystae.homeip.net>
Date: Tue, 11 Jun 2002 22:33:41 GMT
Type: Feature
State: New

Newsgroups: rec.games.mud.lp
From: Tom Jakubowski <tom@crystae.homeip.net>
Subject: XML and LPmud
Message-ID: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net>
Organization: AT&T Broadband
Date: Tue, 11 Jun 2002 22:33:41 GMT

Hi, this is my first post here, but I've been a loyal user of the LP 
driver (in its various forms) for 2 years now. Recently, I started a 
project on my MUD to parse the player save-files, and create a text and 
HTML wizard list.

It took me a long time, until I settled on parsing the .o files, creating 
XML files, and then using XSLT and libxml to create the resulting output 
files. The majority of this was a piece of cake, except for the parsing of 
the .o files. It is a real bitch (pardon language) to parse a file in the 
.o format.

I therefore, propose the following addition to the driver (at least LD):

An option should be given to have save_object() save in an XML format, 
in a standard format, and to have restore_object() restore data in such 
format. No, this doesn't mean that every .o file will look like this:

<ldmud-save>
  <name>miro</name>
  <level>30</level>
  ...
</ldmud-save>

But rather:

<ldmud-save>
  <data name="name" type="string">miro</data>
  <data name="level" type="int">30</data>
  ...
</ldmud-save>

The advantages of this over the "old" format are:

- It is more modern. XML is gaining a strong foothold in the technical 
world, and MUDs shouldn't be left behind.

- Verification. Using DTDs or schemas, MUD admins could create their own 
DTDs which would specify how their savefiles would be layed out for 
various objects, and then validate them.

- Easier parsability. MUD admins could display the data shown here in any 
number of ways: a list of all players, a list of the players with top 
experience, wizards list, etc.

- Standardization. MUD admins could collaborate, and create a standard for 
player savefiles, bulletin board savefiles, etc. and could then share data 
across MUDs. This is, probably, the most exciting part about using XML 
savefiles.

Adding this to the driver shouldn't be *too* hard; it's only a matter of 
modifying save/restore_object(). I haven't looked through at the source 
for *_object() yet (D'oh!), but I imagine it can't be too difficult (at 
least when one gets to writing/reading the file). In fact, I would 
volunteer to do it.

If you have any questions, comments, or flames, pretty please with a 
cherry on top [:)] post them rec.games.mud.lp, rather than emailing them 
to me, just for the sake of community and discussion!

-- Tom Jakubowski (aka Camelot, aka Miro)



From: Tom Jakubowski <tom@crystae.homeip.net>
Subject: Fwp: XML and LPmud
Message-ID: <Pine.LNX.4.44.0206111735001.482-100000@crystae.homeip.net>
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net>
Date: Tue, 11 Jun 2002 22:35:58 GMT

Oh, oops, about the standard:

The standard determined by the LDmud coders would not determine the type 
of or what data is stored, but rather *how* it is stored.

-- Tom Jakubowski





Message-ID: <3D070291.6010207@hotmail.com>
From: Acius <redsorcerer@hotmail.com>
Reply-To: acius@bigfoot.com
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.7) Gecko/20011221
X-Accept-Language: en-us
MIME-Version: 1.0
Newsgroups: rec.games.mud.lp
Subject: Re: XML and LPmud
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 161
NNTP-Posting-Host: 12.254.142.200
X-Complaints-To: abuse@attbi.com
X-Trace: rwcrnsc52.ops.asp.att.net 1023869308 12.254.142.200 (Wed, 12 Jun 2002 08:08:28 GMT)
NNTP-Posting-Date: Wed, 12 Jun 2002 08:08:28 GMT
Organization: AT&T Broadband
Date: Wed, 12 Jun 2002 08:08:28 GMT
Path: uni-berlin.de!fu-berlin.de!e-post.inode.at!news.netway.at!newsfeed.stueberl.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail
Xref: uni-berlin.de rec.games.mud.lp:36940

Tom Jakubowski wrote:

> Hi, this is my first post here, but I've been a loyal user of the LP 
> driver (in its various forms) for 2 years now. Recently, I started a 
> project on my MUD to parse the player save-files, and create a text and 
> HTML wizard list.
> 
> It took me a long time, until I settled on parsing the .o files, creating 
> XML files, and then using XSLT and libxml to create the resulting output 
> files. The majority of this was a piece of cake, except for the parsing of 
> the .o files. It is a real bitch (pardon language) to parse a file in the 
> .o format.


The only subtle trick in parsing .o files is handling arrays and 
mappings properly; all the other variables are simply ints and strings 
(and there's a small header, though I have yet to find any use for it). 
The grammar for arrays and mappings is fairly simple, as such things go.

One point: you *must* have a file-reading library that can differentiate 
between tokens separated by a newline "\n" and a space; the newline is a 
meaningful token in a .o file. If you're writing in C, you should be 
using fgets. If you attempted to write a .o parser using fscanf, or by 
streaming values off an input stream, then you were using the wrong 
tools, and your parsing difficulties are quite understandable.

 > I therefore, propose the following addition to the driver (at least LD):

> 
> An option should be given to have save_object() save in an XML format, 
> in a standard format, and to have restore_object() restore data in such 
> format. No, this doesn't mean that every .o file will look like this:
> 
> <ldmud-save>
>   <name>miro</name>
>   <level>30</level>
>   ...
> </ldmud-save>
> 
> But rather:
> 
> <ldmud-save>
>   <data name="name" type="string">miro</data>
>   <data name="level" type="int">30</data>
>   ...
> </ldmud-save>
> 
> The advantages of this over the "old" format are:
> 
> - It is more modern. XML is gaining a strong foothold in the technical 
> world, and MUDs shouldn't be left behind.


XML is gaining a strong foothold because it's a simple, portable method 
for storing arbitrarily formatted hierarchical data. Perhaps the 
portability could become useful if you find a need to transfer MUD data 
to some other medium; perhaps for transferring it to a database. I 
probably wouldn't rewrite save_object() for that though, I'd just load 
.o file and export it to XML (this can be done quite easily in LPC). As 
for storing data hierarchically, the LDMud data is not inherently 
hierarchical, so there isn't much of an advantage here.

One disadvantage of XML is that the XML version of the file is likely to 
occupy much more disk space than the relatively efficient .o version. 
The "disk space is cheap" argument doesn't work, since a great many 
LPMuds are running in environments with harsh quotas (commercial 
providers and universities are infamous for 10 MB file limits).


> - Verification. Using DTDs or schemas, MUD admins could create their own 
> DTDs which would specify how their savefiles would be layed out for 
> various objects, and then validate them.


One of the most powerful advantages of .o files is that they can be 
loaded by objects that are *not the same type* as the object that 
created the file. If different object types are given different file 
layouts, you will break this extremely useful functionality.


> - Easier parsability. MUD admins could display the data shown here in any 
> number of ways: a list of all players, a list of the players with top 
> experience, wizards list, etc.


Parsing a .o file in LPC and getting all the variables in it is *stupid* 
easy. There's a command on our MUD, 'stat', which works by parsing the 
.o file and displaying all the internal variables. It took maybe an hour 
or two to write.

Here's one way (not our way, but an easy way):
* Read every line in the .o file into an array, say string *vars.
* Delete strings in vars that start with # (this should just be the 
first one)
* For each string in vars, clip the string at the first space. "vars" is 
now a list of all the variables stored in the .o file.
* Create a new .c file. For each entry in vars, append this to the file:
"mixed "+vars[i]+";\n\nquery_"+vars[i]+"() { return "+vars[i]+"; }\n\n"
* At the very end, add a method like this:
"void create() { restore_object(\"" + name_of_o_file + "\"); }\n\n"

This will create a query-able object that holds all the variables in the 
.o file. To use it, load the object you just created, and query each 
variable's value (using the vars array to figure out what the variables 
are). This would be one reasonable way to write an XML converter. 
Perhaps it's not the fastest way, but it's easy to understand, and it 
handles all the data types. BTW, if you're actually going to do this, 
I've already written a function to convert LPC variables to strings. 
Don't reinvent the wheel, use it:

http://www.simud.org/doxygen/simul__efun_8c-source.html#l01923

It handles funny escape characters, arbitrarily wide mappings, and 
similar nagging problems. It doesn't handle a few minor things 
(recursive arrays and closures); these are non-trivial to fix.


> - Standardization. MUD admins could collaborate, and create a standard for 
> player savefiles, bulletin board savefiles, etc. and could then share data 
> across MUDs. This is, probably, the most exciting part about using XML 
> savefiles.


But there is no reason that .o save files cannot already do the same 
thing. Any .o file may be loaded by any object. Any mismatched 
variables, either in the file or in the object, are quitely ignored.

Arguably you could use XML to communicate with non-LP Muds, but the real 
problem is "agreeing on a standard", not figuring out how to get the 
data across once a standard is found. Transferring the data is the easy 
part. If all MUDs were similar to D&D, it would be easier ... 
mercifully, many MUDs are not.


> Adding this to the driver shouldn't be *too* hard; it's only a matter of 
> modifying save/restore_object(). I haven't looked through at the source 
> for *_object() yet (D'oh!), but I imagine it can't be too difficult (at 
> least when one gets to writing/reading the file). In fact, I would 
> volunteer to do it.


The algorithm I sketched above would be a fairly simple way to read in a 
.o file and output a .xml file. Doing the reverse would be quite a bit 
harder, since there's no built-in XML support for LPC (you'd have to 
write your own parser).


> If you have any questions, comments, or flames, pretty please with a 
> cherry on top [:)] post them rec.games.mud.lp, rather than emailing them 
> to me, just for the sake of community and discussion!


I'm not trying to flame you. I do think you should reconsider

your dislike of .o files, however ;-).


-- Acius
Acius@Walraven




From tom@crystae.homeip.net Tue Jun 25 15:39:47 2002
Path: uni-berlin.de!fu-berlin.de!news.maxwell.syr.edu!wn1feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail
Newsgroups: rec.games.mud.lp
From: Tom Jakubowski <tom@crystae.homeip.net>
Subject: Re: XML and LPmud
In-Reply-To: <3D070291.6010207@hotmail.com>
Message-ID: <Pine.LNX.4.44.0206121544170.5392-100000@crystae.homeip.net>
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net>
 <3D070291.6010207@hotmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 91
NNTP-Posting-Host: 12.248.207.231
X-Complaints-To: abuse@attbi.com
X-Trace: rwcrnsc51.ops.asp.att.net 1023915889 12.248.207.231 (Wed, 12 Jun 2002 21:04:49 GMT)
NNTP-Posting-Date: Wed, 12 Jun 2002 21:04:49 GMT
Organization: AT&T Broadband
Date: Wed, 12 Jun 2002 21:04:49 GMT
Xref: uni-berlin.de rec.games.mud.lp:36941

On Wed, 12 Jun 2002, Acius wrote:

> XML is gaining a strong foothold because it's a simple, portable method 
> for storing arbitrarily formatted hierarchical data. Perhaps the 
> portability could become useful if you find a need to transfer MUD data 
> to some other medium; perhaps for transferring it to a database. I 
> probably wouldn't rewrite save_object() for that though, I'd just load 
> .o file and export it to XML (this can be done quite easily in LPC). As 
> for storing data hierarchically, the LDMud data is not inherently 
> hierarchical, so there isn't much of an advantage here.
Right, but exporting a .o file with LPC is relatively useless. Using a
compiled language along with a scheduler like cron is much more
reasonable alternative, as the instruction to reparse the data and create
lists, topscore lists, etc. is automatic.

> 
> One disadvantage of XML is that the XML version of the file is likely to 
> occupy much more disk space than the relatively efficient .o version. 
> The "disk space is cheap" argument doesn't work, since a great many 
> LPMuds are running in environments with harsh quotas (commercial 
> providers and universities are infamous for 10 MB file limits).
I realise that hard drive space is a big problem (and I'm one of the
victims ;)), but this is exactly why it would be an optional choice,
when the admin compiles the driver.
 
> > - Easier parsability. MUD admins could display the data shown here in any 
> > number of ways: a list of all players, a list of the players with top 
> > experience, wizards list, etc.
> 
> 
> Parsing a .o file in LPC and getting all the variables in it is *stupid* 
> easy. There's a command on our MUD, 'stat', which works by parsing the 
> .o file and displaying all the internal variables. It took maybe an hour 
> or two to write.
> 
[snip]
Er, perhaps I didn't make myself clear. I meant that the parsability would
be 200x easier for an admin writing a C/Perl/any-other-language-with-XML-
libraries program, rather than LPC. *Everyone* knows how easy it is to
parse a .o file from LPC, because of its great string functions.

> 
> > - Standardization. MUD admins could collaborate, and create a standard for 
> > player savefiles, bulletin board savefiles, etc. and could then share data 
> > across MUDs. This is, probably, the most exciting part about using XML 
> > savefiles.
> 
> 
> But there is no reason that .o save files cannot already do the same 
> thing. Any .o file may be loaded by any object. Any mismatched 
> variables, either in the file or in the object, are quitely ignored.
> 
I didn't list this, but the ability to load any .o file with any object
is a slight security risk. I suppose this would be true for an
XML-savefile as well.

I guess this security risk could be solved by changing the permissions for 
restore_object() in the master object. But it might be useful for an
individual wizard to specify, when calling save_object(), what objects
can restore from the file. So the new .o file might look like:

#0:0 /* What's this for anyway? */
#valid-restore "players/miro/secret", "players/dralith/secret"
secret_codeword "crystae"

or, if any object can read it, it would look just like an old-style
save-file.

> Arguably you could use XML to communicate with non-LP Muds, but the real 
> problem is "agreeing on a standard", not figuring out how to get the 
> data across once a standard is found. Transferring the data is the easy 
> part. If all MUDs were similar to D&D, it would be easier ... 
> mercifully, many MUDs are not.
> 
Exactly... we could have a central organization, made up of MUD admins,
who would create the standard and then approve MUDs as conforming to the
standard. Sort of like the creation of ANSI C.

> I'm not trying to flame you. I do think you should reconsider
> 
> your dislike of .o files, however ;-).
> 
I don't dislike .o files at all, I'm just supplying an alternative. :)

> 
> -- Acius
> Acius@Walraven

-- Tom Jakubowski (Miro@Crystae, Camelot@Aldebaran)




From fishlover@nospam.net Tue Jun 25 15:39:47 2002
Path: uni-berlin.de!fu-berlin.de!logbridge.uoregon.edu!canoe.uoregon.edu!newsfeed.news.ucla.edu!ucdavis!not-for-mail
From: Cichlidiot <fishlover@nospam.net>
Newsgroups: rec.games.mud.lp
Subject: Re: XML and LPmud
Date: Thu, 13 Jun 2002 00:50:42 +0000 (UTC)
Organization: University of California, Davis
Lines: 32
Sender: Melissa Danforth <mdanfor@runner.ucdavis.edu>
Message-ID: <ae8q92$2dn$1@woodrow.ucdavis.edu>
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net> <3D070291.6010207@hotmail.com> <Pine.LNX.4.44.0206121544170.5392-100000@crystae.homeip.net>
NNTP-Posting-Host: runner.ucdavis.edu
X-Trace: woodrow.ucdavis.edu 1023929442 2487 169.237.105.37 (13 Jun 2002 00:50:42 GMT)
X-Complaints-To: usenet@ucdavis.edu
NNTP-Posting-Date: Thu, 13 Jun 2002 00:50:42 +0000 (UTC)
User-Agent: tin/1.4.3-20000502 ("Marian") (UNIX) (SunOS/5.8 (sun4u))
Xref: uni-berlin.de rec.games.mud.lp:36942

Tom Jakubowski <tom@crystae.homeip.net> wrote:
> I didn't list this, but the ability to load any .o file with any object
> is a slight security risk. I suppose this would be true for an
> XML-savefile as well.

> I guess this security risk could be solved by changing the permissions for 
> restore_object() in the master object. But it might be useful for an
> individual wizard to specify, when calling save_object(), what objects
> can restore from the file. So the new .o file might look like:

> #0:0 /* What's this for anyway? */
> #valid-restore "players/miro/secret", "players/dralith/secret"
> secret_codeword "crystae"

> or, if any object can read it, it would look just like an old-style
> save-file.

Please try to read the source code of save_object() and restore_object()  
(in object.c in Amylaar and LDMud) before posting such questions. If you
had done so, you would know that the #0:0 line is a version number. I'm
assuming the original writers wanted to leave room for possibily
incompatible future versions of save_object() and restore_object(), but
this is just an assumption. 

As for the security, you would also see a call to check_valid_path() in
both, which calls valid_read() for restore or valid_write() for save in
the master object. These calls pass the file being accessed, the function
making the access (restore_object or save_object in this case) and which
object is being saved or restored. You could then implement your master
object to call a special routine which would enforce save/restore
restrictions. For example, my mud only allows the mail program to do
save_object() or restore_object() in the mail directory.


From tom@crystae.homeip.net Tue Jun 25 15:39:47 2002
Path: uni-berlin.de!fu-berlin.de!news.maxwell.syr.edu!wn1feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi_feed3!attbi.com!sccrnsc01.POSTED!not-for-mail
Newsgroups: rec.games.mud.lp
From: Tom Jakubowski <tom@crystae.homeip.net>
Subject: Re: XML and LPmud
In-Reply-To: <ae8q92$2dn$1@woodrow.ucdavis.edu>
Message-ID: <Pine.LNX.4.44.0206122301390.6131-100000@crystae.homeip.net>
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net>
 <3D070291.6010207@hotmail.com> <Pine.LNX.4.44.0206121544170.5392-100000@crystae.homeip.net>
 <ae8q92$2dn$1@woodrow.ucdavis.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 29
NNTP-Posting-Host: 12.248.207.231
X-Complaints-To: abuse@attbi.com
X-Trace: sccrnsc01 1023941173 12.248.207.231 (Thu, 13 Jun 2002 04:06:13 GMT)
NNTP-Posting-Date: Thu, 13 Jun 2002 04:06:13 GMT
Organization: AT&T Broadband
Date: Thu, 13 Jun 2002 04:06:13 GMT
Xref: uni-berlin.de rec.games.mud.lp:36945

> Please try to read the source code of save_object() and restore_object()  
> (in object.c in Amylaar and LDMud) before posting such questions. If you
> had done so, you would know that the #0:0 line is a version number. I'm
> assuming the original writers wanted to leave room for possibily
> incompatible future versions of save_object() and restore_object(), but
> this is just an assumption. 
> 
Thanks for the info - as a matter of fact I don't have a copy of the 
driver source on hand at the moment.

> As for the security, you would also see a call to check_valid_path() in
> both, which calls valid_read() for restore or valid_write() for save in
> the master object. These calls pass the file being accessed, the function
> making the access (restore_object or save_object in this case) and which
> object is being saved or restored. You could then implement your master
> object to call a special routine which would enforce save/restore
> restrictions. For example, my mud only allows the mail program to do
> save_object() or restore_object() in the mail directory.
> 
Maybe if you backtrack a few steps you'd see that I already wrote that. 
I simple suggested that, in addition, an individual coder could determine 
which objects have the permission to restore (or save I guess) from/to the 
.o file. Saying that the current system is ideal is like saying the 
permission system in the LP-2.4.5 mudlib is ideal (where each person's 
access is controlled by an access list in the player's savefile, rather 
than determined by an access file/list in each directory).

-- Tom Jakubowski (Miro@Crystae, Camelot@Aldebaran)



From redsorcerer@hotmail.com Tue Jun 25 15:39:47 2002
Path: uni-berlin.de!fu-berlin.de!news.maxwell.syr.edu!wn1feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi_feed3!attbi.com!sccrnsc02.POSTED!not-for-mail
Message-ID: <3D0815B8.3060106@hotmail.com>
From: Acius <redsorcerer@hotmail.com>
Reply-To:  redsorcerer@hotmail.com
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: rec.games.mud.lp
Subject: Re: XML and LPmud
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net> <3D070291.6010207@hotmail.com> <Pine.LNX.4.44.0206121544170.5392-100000@crystae.homeip.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 65
NNTP-Posting-Host: 12.254.142.200
X-Complaints-To: abuse@attbi.com
X-Trace: sccrnsc02 1023939747 12.254.142.200 (Thu, 13 Jun 2002 03:42:27 GMT)
NNTP-Posting-Date: Thu, 13 Jun 2002 03:42:27 GMT
Organization: AT&T Broadband
Date: Thu, 13 Jun 2002 03:42:27 GMT
Xref: uni-berlin.de rec.games.mud.lp:36943

Tom Jakubowski wrote:
> On Wed, 12 Jun 2002, Acius wrote:
> 
>>XML is gaining a strong foothold because it's a simple, portable method 
>>for storing arbitrarily formatted hierarchical data. Perhaps the 
>>portability could become useful if you find a need to transfer MUD data 
>>to some other medium; perhaps for transferring it to a database. I 
>>probably wouldn't rewrite save_object() for that though, I'd just load a
>>.o file and export it to XML (this can be done quite easily in LPC). As 
>>for storing data hierarchically, the LDMud data is not inherently 
>>hierarchical, so there isn't much of an advantage here.
> 
> Right, but exporting a .o file with LPC is relatively useless. Using a
> compiled language along with a scheduler like cron is much more
> reasonable alternative, as the instruction to reparse the data and create
> lists, topscore lists, etc. is automatic.

I said exporting .o *to XML* with LPC. How can you say this is useless, 
when this is the functionality you were asking for? Converting a .o to a 
.xml is nearly identically difficult to saving straight to .xml, and can 
be done in straight LPC. If you don't like the extra step of converting 
.o to .xml, you'll need to write a driver version, but that's a lot more 
work and doesn't gain you anything I can think of. If you call it 
save_xml() (instead of replacing save_object()), then you get the added 
bonus of not deprecating the millions of lines of existing MUD code, 
while still allowing them to use save_xml() in extending their own libs.

>>One disadvantage of XML is that the XML version of the file is likely to 
>>occupy much more disk space than the relatively efficient .o version. 
>>The "disk space is cheap" argument doesn't work, since a great many 
>>LPMuds are running in environments with harsh quotas (commercial 
>>providers and universities are infamous for 10 MB file limits).
> 
> I realise that hard drive space is a big problem (and I'm one of the
> victims ;)), but this is exactly why it would be an optional choice,
> when the admin compiles the driver.
>  
> 
>>>- Easier parsability. MUD admins could display the data shown here in any 
>>>number of ways: a list of all players, a list of the players with top 
>>>experience, wizards list, etc.
>>
>>
>>Parsing a .o file in LPC and getting all the variables in it is *stupid* 
>>easy. There's a command on our MUD, 'stat', which works by parsing the 
>>.o file and displaying all the internal variables. It took maybe an hour 
>>or two to write.
>>
> 
> [snip]
> Er, perhaps I didn't make myself clear. I meant that the parsability would
> be 200x easier for an admin writing a C/Perl/any-other-language-with-XML-
> libraries program, rather than LPC. *Everyone* knows how easy it is to
> parse a .o file from LPC, because of its great string functions.

True: Outside of LPC, it's easier to read XML because of the libraries 
available for it. But see my earlier comment -- it's wiser to make a 
save_xml() function (either as a simul_efun using a .o->.xml converter, 
or as a driver function), because it won't break existing code.

How would you handle arrays and mappings in XML?

-- Acius
acius _at_ simud _dot_ org



From tom@crystae.homeip.net Tue Jun 25 15:39:47 2002
Path: uni-berlin.de!fu-berlin.de!news.maxwell.syr.edu!wn1feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi_feed3!attbi.com!sccrnsc01.POSTED!not-for-mail
Newsgroups: rec.games.mud.lp
From: Tom Jakubowski <tom@crystae.homeip.net>
Subject: Re: XML and LPmud
In-Reply-To: <3D0815B8.3060106@hotmail.com>
Message-ID: <Pine.LNX.4.44.0206122254140.6131-100000@crystae.homeip.net>
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net>
 <3D070291.6010207@hotmail.com> <Pine.LNX.4.44.0206121544170.5392-100000@crystae.homeip.net>
 <3D0815B8.3060106@hotmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 46
NNTP-Posting-Host: 12.248.207.231
X-Complaints-To: abuse@attbi.com
X-Trace: sccrnsc01 1023940884 12.248.207.231 (Thu, 13 Jun 2002 04:01:24 GMT)
NNTP-Posting-Date: Thu, 13 Jun 2002 04:01:24 GMT
Organization: AT&T Broadband
Date: Thu, 13 Jun 2002 04:01:25 GMT
Xref: uni-berlin.de rec.games.mud.lp:36944

> I said exporting .o *to XML* with LPC. How can you say this is useless, 
> when this is the functionality you were asking for? Converting a .o to a 
> .xml is nearly identically difficult to saving straight to .xml, and can 
> be done in straight LPC. If you don't like the extra step of converting 
> .o to .xml, you'll need to write a driver version, but that's a lot more 
> work and doesn't gain you anything I can think of. If you call it 
> save_xml() (instead of replacing save_object()), then you get the added 
> bonus of not deprecating the millions of lines of existing MUD code, 
> while still allowing them to use save_xml() in extending their own libs.
> 
Ack, you're right. A simul-efun to convert .o to XML would be ideal. I 
never thought until now that along with each save_object() call, I could 
do a save_xml(file) call. :/ Sorry.

> How would you handle arrays and mappings in XML?
Simple (but a *HUGE* waste of hard drive space I'm afraid):

<data type="array" name="my_array">
  <elements>
    # Note that a fictional type "member" would be reserved for arrays
    <data type="member" name="">value_1</data>
    <data type="member" name="">value_2</data>
  </elements>
</data>

or maybe:

<data type="string *" name="my_array">
  <elements>
    <element>value_1</element>
    <element>value_2</element>
  </elements>
</data>

> 
> -- Acius
> acius _at_ simud _dot_ org
> 
> 

BTW, I take my proposal away, as Acius as made me realise that a 
simul-efun (or perhaps a patch to my copy of the driver only, for the sake 
of efficiency) is a *much* better solution.

-- Tom Jakubowski (Miro@Crystae, Camelot@Aldebaran)



From yappo@netg.se Tue Jun 25 15:39:47 2002
Path: uni-berlin.de!fu-berlin.de!newsfeed.vmunix.org!uio.no!news.netg.se!not-for-mail
From: Sten During <yappo@netg.se>
Newsgroups: rec.games.mud.lp
Subject: Re: XML and LPmud
Date: Thu, 13 Jun 2002 09:07:10 +0200
Organization: Calvia TerraTel AB
Lines: 20
Message-ID: <3D08449E.2000100@netg.se>
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net> <3D070291.6010207@hotmail.com> <Pine.LNX.4.44.0206121544170.5392-100000@crystae.homeip.net> <3D0815B8.3060106@hotmail.com> <Pine.LNX.4.44.0206122254140.6131-100000@crystae.homeip.net>
Reply-To: sten@netg.se
NNTP-Posting-Host: fram.netg.se
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: endevour.netg.se 1023952027 20002 212.91.131.12 (13 Jun 2002 07:07:07 GMT)
X-Complaints-To: internet@netg.se
NNTP-Posting-Date: Thu, 13 Jun 2002 07:07:07 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us, sv
Xref: uni-berlin.de rec.games.mud.lp:36947



Tom Jakubowski wrote:

>
> Ack, you're right. A simul-efun to convert .o to XML would be ideal. I 
> never thought until now that along with each save_object() call, I could 
> do a save_xml(file) call. :/ Sorry.
> 


Why on earth keep the outdated save_object at all if you want to use a
different format?

write_file (or whatever your driverversion calls it) and read_file ought
to be enough. With todays processors the performance-hit actually
matters very little.

		Yappo



From redsorcerer@hotmail.com Tue Jun 25 15:39:48 2002
Path: uni-berlin.de!fu-berlin.de!howland.erols.net!news-out.worldnet.att.net.MISMATCH!wn4feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc02.POSTED!not-for-mail
Message-ID: <3D099A26.9070807@hotmail.com>
From: Acius <redsorcerer@hotmail.com>
Reply-To:  acius@bigfoot.com
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: rec.games.mud.lp
Subject: Re: XML and LPmud
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net> <3D070291.6010207@hotmail.com> <Pine.LNX.4.44.0206121544170.5392-100000@crystae.homeip.net> <3D0815B8.3060106@hotmail.com> <Pine.LNX.4.44.0206122254140.6131-100000@crystae.homeip.net> <3D08449E.2000100@netg.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 24
NNTP-Posting-Host: 12.254.142.200
X-Complaints-To: abuse@attbi.com
X-Trace: sccrnsc02 1024039179 12.254.142.200 (Fri, 14 Jun 2002 07:19:39 GMT)
NNTP-Posting-Date: Fri, 14 Jun 2002 07:19:39 GMT
Organization: AT&T Broadband
Date: Fri, 14 Jun 2002 07:19:39 GMT
Xref: uni-berlin.de rec.games.mud.lp:36948

Sten During wrote:
> 
> Why on earth keep the outdated save_object at all if you want to use a
> different format?
> 
> write_file (or whatever your driverversion calls it) and read_file ought
> to be enough. With todays processors the performance-hit actually
> matters very little.

Because save_object() is currently the only method for getting a 
complete list of all the variables in an object. save_object() has 
functionality that would be impossible without an equivalent function 
(namely, assembling a list of all the variables in an object along with 
their values).

It's got very little to do with performance, and far more to do with 
simply having the functionality at all. Replacing save_object() with a 
function which returned a mapping of all the variables in the object 
would be quite acceptable, and actually very nice -- you could implement 
save_object() as a simul_efun then. I believe there's an experimental 
feature to save_object() to a string, which is a step in this direction.

-- Acius



From yappo@netg.se Tue Jun 25 15:39:48 2002
Path: uni-berlin.de!fu-berlin.de!newsfeed.vmunix.org!uio.no!news.netg.se!not-for-mail
From: Sten During <yappo@netg.se>
Newsgroups: rec.games.mud.lp
Subject: Re: XML and LPmud
Date: Fri, 14 Jun 2002 09:24:14 +0200
Organization: Calvia TerraTel AB
Lines: 39
Message-ID: <3D099A1E.70201@netg.se>
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net> <3D070291.6010207@hotmail.com> <Pine.LNX.4.44.0206121544170.5392-100000@crystae.homeip.net> <3D0815B8.3060106@hotmail.com> <Pine.LNX.4.44.0206122254140.6131-100000@crystae.homeip.net> <3D08449E.2000100@netg.se> <3D099A26.9070807@hotmail.com>
Reply-To: sten@netg.se
NNTP-Posting-Host: fram.netg.se
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: endevour.netg.se 1024039450 23977 212.91.131.12 (14 Jun 2002 07:24:10 GMT)
X-Complaints-To: internet@netg.se
NNTP-Posting-Date: Fri, 14 Jun 2002 07:24:10 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us, sv
Xref: uni-berlin.de rec.games.mud.lp:36949



Acius wrote:

> Sten During wrote:
> 
>>
>> Why on earth keep the outdated save_object at all if you want to use a
>> different format?
>>
>> write_file (or whatever your driverversion calls it) and read_file ought
>> to be enough. With todays processors the performance-hit actually
>> matters very little.
> 
> 
> Because save_object() is currently the only method for getting a 
> complete list of all the variables in an object. save_object() has 
> functionality that would be impossible without an equivalent function 
> (namely, assembling a list of all the variables in an object along with 
> their values).
> 
> It's got very little to do with performance, and far more to do with 
> simply having the functionality at all. Replacing save_object() with a 
> function which returned a mapping of all the variables in the object 
> would be quite acceptable, and actually very nice -- you could implement 
> save_object() as a simul_efun then. I believe there's an experimental 
> feature to save_object() to a string, which is a step in this direction.
> 
> -- Acius
> 

You would want to do this anyway as there are times when you want to
be able to force an object to dump its current status. Saving said
status to disk would pretty much be equivalent with save_object. As
far as I know several drivers already enable you to dump status, which
for me makes save_object obsolete.

		Yappo



From julius.2@wright.edu Tue Jun 25 15:39:48 2002
Path: uni-berlin.de!fu-berlin.de!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!cyclone.socal.rr.com!cyclone3.kc.rr.com!news3.kc.rr.com!twister.neo.rr.com.POSTED!not-for-mail
From: julius.2@wright.edu (Matthew Julius)
Newsgroups: rec.games.mud.lp
Subject: Re: XML and LPmud
Message-ID: <3d0a96cd.901626@news-server.woh.rr.com>
References: <Pine.LNX.4.44.0206111715170.467-100000@crystae.homeip.net> <3D070291.6010207@hotmail.com> <Pine.LNX.4.44.0206121544170.5392-100000@crystae.homeip.net> <3D0815B8.3060106@hotmail.com> <Pine.LNX.4.44.0206122254140.6131-100000@crystae.homeip.net> <3D08449E.2000100@netg.se> <3D099A26.9070807@hotmail.com>
X-Newsreader: Forte Free Agent 1.21/32.243
Lines: 25
Date: Sat, 15 Jun 2002 01:49:14 GMT
NNTP-Posting-Host: 24.210.143.234
X-Complaints-To: abuse@rr.com
X-Trace: twister.neo.rr.com 1024105754 24.210.143.234 (Fri, 14 Jun 2002 21:49:14 EDT)
NNTP-Posting-Date: Fri, 14 Jun 2002 21:49:14 EDT
Organization: Road Runner High Speed Online -- Northeast Ohio
Xref: uni-berlin.de rec.games.mud.lp:36950

On Fri, 14 Jun 2002 07:19:39 GMT, Acius <redsorcerer@hotmail.com>
wrote:

>Because save_object() is currently the only method for getting a 
>complete list of all the variables in an object. save_object() has 
>functionality that would be impossible without an equivalent function 
>(namely, assembling a list of all the variables in an object along with 
>their values).

This is not entirely correct.

In LPMud and LDMud any object can get a list of its own variables
using symbol_variable() and a while loop.  An object can get a list of
variables in a different object using the same routine and
bind_lambda().  Of course, such a thing has to be very privileged to
do this, and it's kind of a backwards way of doing it.  It works fine
though.

You can also assign values to variables directly using the same
technique, albeit with a bit more funkiness.

--
Matthew Julius

julius.2@wright.edu