uglycode-coders — UM1 Coders

Re: [UM1-coders] Erm, it doesn't compile

[Chisel W. <ch...@he...>]

On Mon, Jan 28, 2002 at 06:49:23AM +0000, ReaperMan wrote:
> It could be that I am on gcc 2 and everyone else is on 3
AFAIK I'm using gcc2.

> I checked in my changes (oh god) with this as is.
It wouldn't compile so you checked it in?

-- 
Chisel Wright (ch...@he...)

Typer of code; tearer of hair.

[UM1-coders] Hate

[ReaperMan <re...@re...>]

People will hate me for my crimes:

1. I have created context::dump_email_addresses() which does that.
I wasn't sure where we put a shared function like this but I think it
needed to know context (actually possibly not). Some guidance would be
handy.

2. When writing it out I have used a loop and fprinted it to the fp.
Don't know if there is significant overhead but I was not sure how
we are meant to create and use string buffers in the new order of
things. Again, could I have some guidance on this whole new string
thing (specifically here how to put all the aliases into a buffer
to write out once).

Thanks,

Reaps the fully qualified inept.
-- 
-------------------------------------------------------------------------------
                re...@re...         +44 7976 696 407
-------------------------------------------------------------------------------

[UM1-coders] Erm, it doesn't compile

[ReaperMan <re...@re...>]

Well I am sure it compiles for everyone else otherwise it
would be checked in and I know someone said that this
doesn't compile on their system too:

  terminal_type.clear();

g++ -c -g -Wall -Wcast-qual -Wparentheses -Wwrite-strings -Wconversion 
interface.c
interface.c: In method `enum Command_status 
descriptor_data::terminal_set_termtype(const CString &, int)':
interface.c:4271: no matching function for call to `String::wclear 
(WINDOW *&)'
*** Error code 1
make: Fatal error: Command failed for target `interface.o'

It could be that I am on gcc 2 and everyone else is on 3

I checked in my changes (oh god) with this as is.

Reaps.

[UM1-coders] releasing

[Chisel W. <ch...@he...>]

I'm not sure if this is right; one bit I'm sure is wrong:

ssh something.uglymug.org.uk
mkdir cvs
cd cvs
export CVS_RSH=ssh
cvs -z3 -d:ext:USE...@cv...:/cvsroot/uglycode co UglyCODE
cd UglyCODE/
make newversion
make
vi tag_list
make
cp netmud ~uglymug/ugly/netmud_XXX
cvs tag um1_025


I edited the "$Name " bit on the first line of tag_list, which *can't* be right.
I think I have the right moves, but probably in the world's worst order...



Grim, could you let us know 'the proper way' to do this?



Chiz



-- 
Chisel Wright (ch...@he...)

Typer of code; tearer of hair.

Re: [UM1-coders] Releasing Packages

[Chisel W. <ch...@he...>]

On Fri, Jan 25, 2002 at 12:41:05PM +0000, Chisel Wright wrote:
> Then go to: https://sourceforge.net/project/admin/editpackages.php?group_id=33517
> - New Package Name: uglycode-${TAG}
> - edit the release
> - fill in details
> - select file from list

OK, noting what I did for 1.024:

go to: https://sourceforge.net/project/admin/editpackages.php?group_id=33517
New Package Name: uglycode-${TAG}
[Create This Package]
[Add release]
New Release Name: uglycode-${TAG}
[Create This Release]

(mozilla was slow; so I then)
Edit/Release files
Edit This Release
[Paste in tag-info from: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/uglycode/UglyCODE/tag_list
[x] Preserve my pre-formatted text.
[Submit / Refresh]

Select the tarball from the Add Files Section
[Add Files / ...]

Scroll down; choose Any & source .gz
[Update / Refresh]

Go to: https://sourceforge.net/projects/uglycode/
The release should be listed. The file can take up to 30 minutes to appear on the download page.

Now I can go and get run over by a bus.

Chiz

-- 
Chisel Wright (ch...@he...)

Typer of code; tearer of hair.

[UM1-coders] Releasing Packages

[Chisel W. <ch...@he...>]

I think I've manages it;
the process seems to be [summarised from https://sourceforge.net/docman/display_doc.php?docid=6445&group_id=1]:

cvs -d:pserver:ano...@cv...:/cvsroot/uglycode login
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/uglycode co UglyCODE
rm -rf UglyCODE/CVS
tar vczf uglycode-${TAG}.tar.gz UglyCODE
ftp upload.sourceforge.net
* Login as "anonymous"
ftp> bin
ftp> cd /incoming
ftp> put uglycode-${TAG}.tar.gz
ftp> quit

Then go to: https://sourceforge.net/project/admin/editpackages.php?group_id=33517
- New Package Name: uglycode-${TAG}
- edit the release
- fill in details
- select file from list


I got a bit vague near the end becuase I didn't want to create another
release just to confirm the steps.


-- 
Chisel Wright (ch...@he...)

Typer of code; tearer of hair.

Re: [UM1-coders] cgitelnet interface

[J.P. K. <jp...@he...>]

> I presume that this will also reduce the amount of network traffic
> that it sends. When I tested it from home a few days ago using a
> dial-up connection, it was using 100% of the available bandwidth.

No, the change I made before that, whereby it doesn't send a
<!-- --> on every single loop, but only if it hasn't
sent something in the last 25 seconds did that.

> I presume it is doing a non-blocking read then? Should be
> easy to convert to using select() with a timeout (which will
> also give you your millisecond 'capable' timer).
> 
> If you point me at the code, I'll have a look.

/home/julian/cgitelnet/src/cgitelnet_msg.cgi.c

is the specifically relevant file, but everything under
/home/julian/cgitelnet is relevant one way or another.

I have made that entire tree rw to group uglymug.

If you are looking at it, keep half an eye/braincell on how
to modify the msgsnd and msgrcv portions of the code, which take
parameters from a different program which extracts them from the
html form - I'd like to, in the longer term, allow that to be more
configuration file driven.

> Again, if you want I'll take a look.

Be my guest.  I've merely tidied the code up enough to make it
usable.  All my changes from the original CVS checkedout
code have a comment with JPK in them, so you can search on that
if you want to see what I have done.

> > * However, if noone has any objections I'm probably going to 
> > add it to  *
> > * a subdirectory in the Uglymug source tree.                  
> 
> Go for it, as long as we remember to point out that it has
> a different licence from the main source.

*nod*  Actually I'll wait a bit to see if the current author gets
back in touch with me - I emailed him to see if he wanted any
of the changes that I had made, since thuse far, with the exception
of hardwiring in 'uglymug.org.uk' and '6239' all the changes
I have made have been generic.  

> I can't see us writing additional code specifically for web
> support, especially if we can use someone else's code to do
> it for us.

Well it is a question of efficiency - this isn't an efficient way
of doing it in CPU cycles, but it beats the crap out of the inefficiency
of writing it from scratch.

> Adrian.


Julian

P.S.  For those that care, in order to get this working I installed
autoconf and automake, this will remain available unless we run out
of space.  We currently have 244Mb left on a 1.7G disk, which if memory
serves is smaller than wyrm had?

RE: [UM1-coders] cgitelnet interface

[Adrian S. J. <AS...@pa...>]

> From: J.P. King [mailto:jp...@he...]
>=20
> Ok,
>=20
> I've added a small delay in the loop on cgitelnet, and it now
> pauses for 1000th of a second at the end of each loop.  I imagine=20
> that it ought to be event driven, but even this small change=20
> has dropped
> the CPU usage from 100% down to ~0.06%, and a quick test indicates
> that it isn't affecting the performance of the actual interface
> in a perceptible way.

I presume that this will also reduce the amount of network traffic
that it sends. When I tested it from home a few days ago using a
dial-up connection, it was using 100% of the available bandwidth.

> The code should probably be changed to be event driven rather than
> a polling loop, but that is more than I am planning on doing=20
> in the short
> term.  Similarly I ought to use setitimer and getitimer, but I
> am lazy and using usleep.

I presume it is doing a non-blocking read then? Should be
easy to convert to using select() with a timeout (which will
also give you your millisecond 'capable' timer).

If you point me at the code, I'll have a look.

> I have a few enhancements that should probably be made, like=20
> being able
> to select whether to attempt to use the javascript or not.  Also, need
> to see how to stop it being quite as spaced out as it is at=20
> the moment,
> where it adds three lines between lines which are generated=20
> separately.
> Also the colours could do with sprucing up. =20

Again, if you want I'll take a look.

>=20
> **************************************************************
> ***********
> * However, if noone has any objections I'm probably going to=20
> add it to  *
> * a subdirectory in the Uglymug source tree.                 =20
>           *
> **************************************************************
> ***********

Go for it, as long as we remember to point out that it has
a different licence from the main source.

I can't see us writing additional code specifically for web
support, especially if we can use someone else's code to do
it for us.

>=20
> Julian

Adrian.

[UM1-coders] cgitelnet interface

[J.P. K. <jp...@he...>]

Ok,

I've added a small delay in the loop on cgitelnet, and it now
pauses for 1000th of a second at the end of each loop.  I imagine 
that it ought to be event driven, but even this small change has dropped
the CPU usage from 100% down to ~0.06%, and a quick test indicates
that it isn't affecting the performance of the actual interface
in a perceptible way.

The code should probably be changed to be event driven rather than
a polling loop, but that is more than I am planning on doing in the short
term.  Similarly I ought to use setitimer and getitimer, but I
am lazy and using usleep.

I have a few enhancements that should probably be made, like being able
to select whether to attempt to use the javascript or not.  Also, need
to see how to stop it being quite as spaced out as it is at the moment,
where it adds three lines between lines which are generated separately.
Also the colours could do with sprucing up.  

*************************************************************************
* However, if noone has any objections I'm probably going to add it to  *
* a subdirectory in the Uglymug source tree.                            *
*************************************************************************

I make that stand out, because I want to make sure you have all had a 
chance to object before I do it - you might feel it is in appropriate
to add to this tree - my view is that a web interface is important, and
that this does offer that option, thus unless someone is planning on
adding their own this should become part of the project.

Julian

[UM1-coders] Subtle coding bug (hence using this alias) in @remote

[Adrian S. J. <AS...@pa...>]

Ok, there is a subtle bug in @remote to do with @chpid.

The problem is that the following code will never work properly.

        /* CHPID is carried over an @remote */
        context *remote_context =3D new context (player);
        remote_context->commands_executed =3D commands_executed+1;
        remote_context->set_effective_id(get_effective_id());

        /* Crash trap: Make sure we know how many commands we've =
executed for limiting recursion. */
        remote_context->set_depth_limit(depth_limit);
        if (in_command ())
        {
                remote_context->calling_from_command ();
//              remote_context->call_stack.push (new =
Compound_command_and_arguments (get_current_com
mand(), remote_context, get_simple_command(), get_arg1(), get_arg2(), =
get_effective_id(), 0));
        }
        remote_context->process_basic_command (command.c_str());
        mud_scheduler.push_express_job (remote_context);
        copy_returns_from (*remote_context);
        delete remote_context;

This is because set_effective_id requires there to be something on
the call stack to set the id on.

Anyone got a suggestion on how to fix this?

I've already tried doing the call_stack.push (anyone know why this was
removed?), and putting the set_effective_id after that.

Adrian.

--
Adrian St. John
Software Engineer
Pan Security International Ltd.
T 0121 780 0619
as...@pa...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
Pan Security International Limited, Vienna House, International Square, =
Birmingham International Park, Bickenhill Lane, Solihull B37 7GN United =
Kingdom.  Registered company number 3965174=20
This message may contain information which is confidential and subject =
to legal privilege.  If you are not the intended recipient, you may not =
peruse, use, disseminate, distribute or copy this message.  If you have =
received this message in error, please notify the sender immediately by =
e-mail, facsimile or telephone and return and/or destroy the original =
message. Pan Security International Limited accept no responsibility for =
any changes made to this message after it has been sent by the original =
author.

Re: Solaris, mv and netmud.old (was RE: [UM1-coders] Object Store)

[ReaperMan <re...@re...>]

> Certainly I had told Keith in the past to mv the old binary out of the
> way rather than just copy over the top.
Just a note, not sure what happened to it before but when we add

a new binary can we please keep all the previous ones (unless they
are *seriously* defective). Currently we only have the current one
and the next one. This is an issue because if Grim is not
around we will have to check source out etc and build it while
the game is down. Disk space is not much of an issue on the machine
so I think a line of netmud_0XX would be fine...




-- 
----------------------------------------------------------------------
       re...@re...  www.reaperman.org  +44 7976 696 407
----------------------------------------------------------------------

RE: [UM1-coders] Object Store

[Peter C. <pet...@ne...>]

> From: J.P. King [mailto:jp...@he...]
> _10000_ ?  I find that hard to swallow

By the time you've done all the data structure marshalling and
demarshalling, it's about right --- especially in a client-server
environment where you have thread locks and the like.  You can get c. 100M
memory accesses per second, but 10k IPC calls per second is pretty good.  I
can point you at some interesting Web sites if you want, notably the TAO
site (which is the ORB I'm using for work right now).

> No we aren't up to 10,000 times, but we are well into the hundreds.
> Once you get up to a multiple GHz CPU we should more or less 
> be there. :-)

And?  This leaves us where we were ten years ago: we can't have a large
system, because it's too slow.

> The main delay with multiple processes is context switching, but if
> you only have two active processes this shouldn't be much of an issue.
> If the delay were _quite_ as bad as you are suggesting then why don't
> all this big database people build webservers, and the like, 
> into their
> SQL servers - I am sure that people would pay for a factor of 
> 10 increase, let alone a factor of 10000.

Increasingly, they do.  In-process data servers have a long and
distinguished history.

> The object store will be able to bounce back faster than the mud with
> the object store built in by virtue of the fact that there will be
> less code.

Er... what?  Half a second, maybe, for loading the extra code into RAM.

		- Peter

Re: [UM1-coders] Object Store

[J.P. K. <jp...@he...>]

> IPC via anything other than shared memory is roughly 10,000 times slower
> than in-process memory reference.  IPC via shared memory would be liable to
> exactly the same problems we have now, namely data corruption.

_10000_ ?  I find that hard to swallow, but assuming that it is
true, this means that if you can make the access 10000 times faster
than you need it to be then this isn't a problem.

The game used to run on a 16MHz 68020 as I recall, but lets say we
talk about the 20-25MHz IPC that it used to run on - now lets compare
this with a 167MHz Ultra1, with its improved memory access.  Now
compare that to a dual CPU E250 (which is what I expect the next
machine to be at present).

No we aren't up to 10,000 times, but we are well into the hundreds.
Once you get up to a multiple GHz CPU we should more or less be there. :-)

The main delay with multiple processes is context switching, but if
you only have two active processes this shouldn't be much of an issue.
If the delay were _quite_ as bad as you are suggesting then why don't
all this big database people build webservers, and the like, into their
SQL servers - I am sure that people would pay for a factor of 10 increase, 
let alone a factor of 10000.

> ... assuming the data has remained internally consistent.  This seems
> unlikely.
The object store will be able to bounce back faster than the mud with
the object store built in by virtue of the fact that there will be
less code.

Whether the Object Store copes well with the stress we would want to
impose on it is another matter.  If it doesn't then it isn't the product
for us.

> > How expensive are the non-free ones?
> Multiple hundreds to multiple thousands of pounds per seat, from memory.
> Server licences are more.
Oh well, bang goes that idea then ;-)

> 		- Peter


Julian

Re: Solaris, mv and netmud.old (was RE: [UM1-coders] Object Store)

[J.P. K. <jp...@he...>]

> My understanding was that certain version of mv will unlink() the
> target if it exists, and other will creat(O_TRUNC) (or whatever
> the correct argument is).

My understanding is that mv will retain the same inode, which
in some situations is a desirable behaviour, and thus the
system will get as confused if you mv as if you catted over the top.

Certainly I had told Keith in the past to mv the old binary out of the
way rather than just copy over the top.

> Adrian.

Julian

Solaris, mv and netmud.old (was RE: [UM1-coders] Object Store)

[Adrian S. J. <AS...@pa...>]

> From: Peter Crowther [mailto:pet...@ne...]
>=20
> > From: Adrian St. John [mailto:AS...@pa...]
> > I've found the reason for that happening; It occurs if you
> > overwrite the running executable. Solaris nicely trashes the
> > entire game because the 'mv' seems to truncate the file, rather
> > than unlink & recreate.
>=20
> Er... I thought most *nixes did that.  I always moved the old=20
> file out of
> the way, then copied the new one to the old patchname, which=20
> is why you got
> netmud.old... or am I talking out of my hat here?

My understanding was that certain version of mv will unlink() the
target if it exists, and other will creat(O_TRUNC) (or whatever
the correct argument is).

Anyway, this should no longer happen, as in our cunning new way
of running things, we name netmud after the release version
(eg netmud_019 is the currently running process), and have a
soft-link named netmud.

That way the process list shows which version we're running.
It also means that we get to keep older (known stable) versions
around without trying to be clever with the naming convention.

One day I'll get the Makefile to do the rename bit automatically
(The release version is only used if you check out a formal
release level, so normal hacking on the code wont be affected.)

Adrian.

RE: [UM1-coders] Object Store

[Peter C. <pet...@ne...>]

> From: Adrian St. John [mailto:AS...@pa...]
> I've found the reason for that happening; It occurs if you
> overwrite the running executable. Solaris nicely trashes the
> entire game because the 'mv' seems to truncate the file, rather
> than unlink & recreate.

Er... I thought most *nixes did that.  I always moved the old file out of
the way, then copied the new one to the old patchname, which is why you got
netmud.old... or am I talking out of my hat here?

> Not that I can tell. All it gives you is a way of storing arbitrary
> objects to disk, and it looks like it does it by having a custom
> memory allocator that writes into a mmap'd file.

Bugger that, then; it's no better, and in some ways worse, than the current
technique.  At the minimum, I'd want one that could handle transactions.

		- Peter

RE: [UM1-coders] Object Store

[Adrian S. J. <AS...@pa...>]

> From: Peter Crowther [mailto:pet...@ne...]
> > From: Adrian St. John [mailto:AS...@pa...]
> > Taking a step back, what problem are we trying to solve?
>=20
> I have no idea.  I presume it's the problem that the game=20
> sometimes crashes
> without a database dump.  This is rare, and getting rarer.  I=20
> can see no
> other reason for using such a database.

I've found the reason for that happening; It occurs if you
overwrite the running executable. Solaris nicely trashes the
entire game because the 'mv' seems to truncate the file, rather
than unlink & recreate.

> > If we're looking for a secure way of storing the data, then
> > this isn't it. It is in-process, and therefore prone to the
> > same problems we have already (if we crash unexpectedly the
> > data could be in a bad state).
>=20
> Does it transaction-log?

Not that I can tell. All it gives you is a way of storing arbitrary
objects to disk, and it looks like it does it by having a custom
memory allocator that writes into a mmap'd file.

Adrian.

RE: [UM1-coders] Object Store

[Peter C. <pet...@ne...>]

> From: J.P. King [mailto:jp...@he...]
> > Yes.  Users have come to expect the site to be fast.
> And the overhead of another process is really going to 
> impinge on this?
> I don't see it myself - we aren't talking about starting a 
> new process, merely talking to an already running one.

IPC via anything other than shared memory is roughly 10,000 times slower
than in-process memory reference.  IPC via shared memory would be liable to
exactly the same problems we have now, namely data corruption.

> Sorry, I don't see why a MUSH database going tits up means that
> Ugly having a separate persistant store to the main game engine
> process.  The Object store should be fast enough that if it falls
> over it can be made to bounce back up rather fast...

... assuming the data has remained internally consistent.  This seems
unlikely.

> How expensive are the non-free ones?

Multiple hundreds to multiple thousands of pounds per seat, from memory.
Server licences are more.

		- Peter

RE: [UM1-coders] Object Store

[Peter C. <pet...@ne...>]

> From: Adrian St. John [mailto:AS...@pa...]
> Taking a step back, what problem are we trying to solve?

I have no idea.  I presume it's the problem that the game sometimes crashes
without a database dump.  This is rare, and getting rarer.  I can see no
other reason for using such a database.

> If we're looking for a secure way of storing the data, then
> this isn't it. It is in-process, and therefore prone to the
> same problems we have already (if we crash unexpectedly the
> data could be in a bad state).

Does it transaction-log?

		- Peter

Re: [UM1-coders] Object Store

[J.P. K. <jp...@he...>]

> (Yes, I'm following up to my own post...)
> 
> Taking a step back, what problem are we trying to solve?
> 
> If we're looking for a secure way of storing the data, then
> this isn't it. It is in-process, and therefore prone to the
> same problems we have already (if we crash unexpectedly the
> data could be in a bad state).

*nod* - but I assume that you can make a separate object store with
this, and then link this, and the original together via a
socket/pipe/rpc/sharedmmap - am I wrong?

This is why you want the abstraction layer, so that you can start
with the code in one place, and then move it around, only needing
to modify the abstraction layer to change where the work happens.

> I think that what we're really after is an out-of-process
> object store that can be connected to by different processes
> (UglyMUG engine, Web interface, low-level db hacking tool)
> at the same time, and provide a minimal amount of consistancy
> (eg no half-written strings, having to use a database snapshot
> from up to an hour ago).

*nod*  This is something that I would consider a vital aim for
some point in the future, yes.

> Admittedly in front of that should be a local-process cache
> that holds some details (the common strings, flags, etc), or
> possibly the whole object, or even depending on what we're
> doing, tell the database how much to cache.

Broadly I consider this to be a detail - an important one, but
a detail none the less.  Given that we don't want to write
our own Object Store we need one which more or less meets our
requirements.

Then we need to make sure that it can be bent enough to exactly
meet our requirements.
Then the work starts.  :-)

Will coldstore be able to replace the current 'object store' that
the game uses?  - If so then it is viable enough to consider.


The consideration needs to include - can we make it a separate
processes to the game engine?  
Do we need write through caching to give us enough speed?  If so
can we implement it with this product?

etc.


I am relatively happy with the idea of moving our current object
store out into a separate process if people think that is a sane
idea - but my impression is that noone had a good opinion of our
DB engine as it stood at the moment.  Is this wrong?

> Adrian.

Julian

RE: [UM1-coders] Object Store

[Adrian S. J. <AS...@pa...>]

> From: Adrian St. John=20
>=20
> > From: J.P. King [mailto:jp...@he...]
> >=20
> >=20
> > Having said I could only find one so far, I then find another, which
> > is more our cup of tea:
> >=20
> > http://sourceforge.net/projects/coldstore/
> >=20
> > I haven't looked at the code itself yet.
>=20
> Quote from their website:
>=20
> MUDs, MOOsm MUSHes, M*=20
> It's a good way to store those objects. [ColdStore could=20
> almost have been designed to implement a M* :) ]
>=20

(Yes, I'm following up to my own post...)

Taking a step back, what problem are we trying to solve?

If we're looking for a secure way of storing the data, then
this isn't it. It is in-process, and therefore prone to the
same problems we have already (if we crash unexpectedly the
data could be in a bad state).

I think that what we're really after is an out-of-process
object store that can be connected to by different processes
(UglyMUG engine, Web interface, low-level db hacking tool)
at the same time, and provide a minimal amount of consistancy
(eg no half-written strings, having to use a database snapshot
from up to an hour ago).

Admittedly in front of that should be a local-process cache
that holds some details (the common strings, flags, etc), or
possibly the whole object, or even depending on what we're
doing, tell the database how much to cache.

Adrian.

Re: [UM1-coders] Object Store

[J.P. K. <jp...@he...>]

> MUDs, MOOsm MUSHes, M* 
> It's a good way to store those objects. [ColdStore could almost have been designed to implement a M* :) ]
> 

Cool.

> I have to say it is a nice idea; we'd still need to dump the database
> like we do at the moment for backup and for modifying the Object
> classes (it states that you can modify the classes as long as you
> don't change the layout or virtual methods, which is exactly what
> we'd want to do).

Well we'd want it to be dumped anyway, so that we can do backups
and stuff... talking of which, we really should do that again..

> When I've got time I'll have a play with it and see how painful
> it might be.
> The only problem might be the lack of portability between platforms.
> (But if we're keeping the database dumps, then that isn't too much
> of a problem.)

Ok, I'll have a look at getting the code onto the standard platform
(I guess Linux) and thence to port it to Solaris and possibly
FreeBSD - or at least see how painful it is.  Should be able to do that
later today, either before I leave work or perhaps between Farscape 
and Enterprise.

> Adrian.

Julian

RE: [UM1-coders] Object Store

[Adrian S. J. <AS...@pa...>]

> From: J.P. King [mailto:jp...@he...]
>=20
>=20
> Having said I could only find one so far, I then find another, which
> is more our cup of tea:
>=20
> http://sourceforge.net/projects/coldstore/
>=20
> I haven't looked at the code itself yet.

Quote from their website:

MUDs, MOOsm MUSHes, M*=20
It's a good way to store those objects. [ColdStore could almost have =
been designed to implement a M* :) ]


I have to say it is a nice idea; we'd still need to dump the database
like we do at the moment for backup and for modifying the Object
classes (it states that you can modify the classes as long as you
don't change the layout or virtual methods, which is exactly what
we'd want to do).

When I've got time I'll have a play with it and see how painful
it might be.
The only problem might be the lack of portability between platforms.
(But if we're keeping the database dumps, then that isn't too much
of a problem.)

Adrian.

Re: [UM1-coders] Object Store

[J.P. K. <jp...@he...>]

Having said I could only find one so far, I then find another, which
is more our cup of tea:

http://sourceforge.net/projects/coldstore/

I haven't looked at the code itself yet.

Thoughts welcome, as ever.

Julian

Re: [UM1-coders] Object Store

[J.P. K. <jp...@he...>]

> > No, it wouldn't.  Is this really a problem?
> Yes.  Users have come to expect the site to be fast.
And the overhead of another process is really going to impinge on this?
I don't see it myself - we aren't talking about starting a new process,
merely talking to an already running one.

> > Does this problem outweigh the potential benefits?
> Yes.  Witness the number of times I've seen MUSH databases go tits-up.
> However, see later.
Sorry, I don't see why a MUSH database going tits up means that
Ugly having a separate persistant store to the main game engine
process.  The Object store should be fast enough that if it falls
over it can be made to bounce back up rather fast...

> > Yes, although ideally we'd like ways of atomising operations, or
> > supporting rollback.
> 
> Quite.
> 
> [Below] The modern C++ object stores can do transparent, transactional
> persistence and object caching in-process.  If there's a free one, it would
> certanly be worth investigating.  But we shouldn't try to roll our own.

I absolutely agree that we shouldn't start from scratch and roll our own.
I am trawling a few places to see what I can see, thus far only one looks
interesting enough to even investigate, although that is in Java.

How expensive are the non-free ones?

> 		- Peter

Julian