Ok... this is a merger of two pieces of email that I think cover the
SGMlily issues, along with some other issues...
>>> Second, I have heard a lot about maintaining who/what lists.
>>Initially, I liked this idea a lot... then I realized something:
>>
>>This causes a duplication of the database in both the server and
>>client, and might begin to cause skew problems... sure - there
>>_shouldn't_ be any... but we've had experience in th past that it
>>_does_ happen... (ie - Clover).
>>
> I think we should simply chalk many of the bugs which crept up in Clover
>as learning experiences.
As long as we learn from them and move on - I think the next
suggestion indicates a good way to do so.
> I think there is. The architecture of many publicly available distributed
>systems, from the simplistic DNS to more complex systems like Arjuna, have
>show the serial number/timestamp to be a great way to age and monitor
>conditions in a distributed system. Perhaps the addition of these types
>of tools is a good way to prevent Clover-style database creap.
I think so too, and I think this works well with some of the other
schemes that have been proposed and that we're discussion.
I'd propose that for all databse type information, the server provide
a unique serial number that should be treated as either a massively
long integer or as a string (so it must be made to be increasing by
normal string rules). This "serial" tagwould be included with all
user and group information., including status messages. Remember that
status messages might have to be sent out even if notifies are off.
>>> Lastly, (I'm sure people are glad to hear that) I have the following
>>>suggestions for server->client information sharing:
> How about switching to a SGML-style system?
> <WHO><OBJECT><NAME></NAME><BLURB></BLURB><STATE><ONSINCE><LAST_INPUT>
> <FLAGS></WHO>
I think you're on track here, with some possible variations in the
syntax (and I forget offhand if we discuss this later). Mind you, I'm
not thrilled about having to possibly parse this with the optional
whitespace allowed - but once I develop a library or use one I find it
should be easy.
<USER SERIAL="unique serial number for this user" OBJECT="server
assigned object ID that will be the same for the 'life' of this user">
(Inside we put all the changed attributes for the user object, or the
complete set for providing initial info. I provide some, not all,
examples.)
<NAME>user name</NAME>
<BLURB>user blurb</BLURB>
<ONSINCE TIMEFORMAT="how is this formatted">whatever</ONSINCE>
And then we might provide a plaintext, preformatted, representation to
print to the screen.
</USER>
>>1) Parsing the blurb part may be difficult because ][ is allowed
>>inside the blurb... not impossible, however, so I'll just mention it
>>as a warning for future implementers...
>>
> Yeah. That will be a real concern, maybe the suggestion above is alright?
Putting the blurb by itself solves this problem.
>>2) "flags" can cause problems when the server adds things... we need
>>some way to define what the flags mean _dynamically_, which will cause
>>problem after problem... (or we need to make potential changes to that
>>(and all fields) rare). I have to wonder what else in there may be
>>subject to this problem (such as the event information).
>>
> Yeah. I suspect we will just need to do protocol versioning again, as I
>do in the server with clients.
There can also be a flag in the <FLAG> tag (follow?... {: ) indicating
more than one version of the flag, or what the flag fields translate
to... or so mething like that...
>>3) I'm unclear what "recips,subjects" indicates... will this be an
>>object number reference?...
>>
> Yes.
See how I proposed this above. Is this an acceptable reference
method?
>>4) Will the server be sending all this information even if there is no
>>accompanying "formatted text" because the person has, for example,
>>turned that notify off?... or is not a member of that discussion?...
>>(is it reasonable for me to want to know who is in a diiscussion I am
>>not a member of?...)
>>
> I don't think that is reasonable to know. I imagine a "good" (meaning
>polite) UI would just have a refresh button for discussions you are not
>not a member of to refresh membership lists.
Well... question still applies for stuff that I have notifications
turned off for. Should we assume we get this information?
>>5) OH! Wait... "variant_client_info" is some way for the client to
>>determine what window/screen/whatever to route things to?... hrm...
>>is this going to be tied to something raw so the client can still take
>>advantage of server formatting if wanted?... (do others want this?...)
>>
> Right. The client can tell the server, "when an event happens for 'foo'
>send me the following data as well as the normal stuff". This will allow
>you to use the server as a kind of data store.
Is the threaded information we discuss later part of this? (I assume
the threaded stuff changes some of my formatting proposal above, but
we'll get to that.)
The big issue to remember (At least that I need to keep reminding
myself) is ththere are two kinds of events - stuff that is sent in
response to a command/query, and stuff that the server sends as a
nitification/message to the user that is unsolicited. (We can think
of the former as a database query and the latter as a standing query
or event.)
>>> Now, Prisoner "harp[ed]" in his last message about all the other tables
>>>in the database. I suggest that any infromation which does not comprise
>>>the user is open for viewing. Just as there are now client commands to get
>>>the verb list, there should be client command to get any other tabular
>>>information in the server, or query for information. Let there be #$# info
>>>and #$# finger and other such commands!
>>
>>How about something more general, both for the server and client
>>(again, for pubvlic infromation only...) say...
>> #$# query person label
>>would return
>> %query person label value
>>or
>> %query_rejected person label "reason"
>>
>>(My thoughts on this one would be to query the gender if no icon is
>>set for the person to create a "default" icon... or some such...)
>>
> Hrm. This is interesting... I am going to want to think about this more.
>Have you had any further thoughts?
Well... In my last paragrph, which I should have put here (but my
network sucks and I'll probably wipe out the document if I try), I
tried to make the point that everything is just a database... we have
specialized commands to query parts of the database - I want a more
generalized way to access the data at the same time. The
#$# query person label
proposal was a very crude way of doing some of this, and not a very
powerfull one. Keep thinking abotu this, however...
>>> I am deeply interested in hearing what people think about this, and what
>>>people's plans and ideas are. What is above is only a half-baked loaf! :)
>>
>>I'm pondering it all as well... It's clear we're going to have to
>>build some sort fo database... tho everythign we'ev talked about will
>>make something like lhub easier.
>>
> We have a database now. Keep in mind at its heart MOO is just a persistent
>object database system.
With very fixed query methods... I think my point here was more aimed
at query methods and not storage methods...
> In the case of MOO/lily we can take this idea and point it at clients.
>Each user would have a client module object which snaps onto their player
>object when they connect.
YES! I keep looking to design a modular system where you just snap in
a new protocol and it determines the protocol to use based on port
connected or some other factor.
Now... skipping to the other message...
>>3) Something, anything, where I can be assured that I will not get
>> another login prompt so I can exit the ugly part of my state
>> machine. I was parsing on the "Welcome to lily;" prompt, but this
>> isn't assured; I'd like the line before this to read (something
>> like)
>> %connected logged_in
>> or something.
>>
> Yeah. Hrm.... I have been thinking more advanced clients ought to be able
>to handle the login process themselves:
>
> #$# login username password
> %login OKAY
> %login FAIL
This is sent before the client identifies itself? How does this
integrate with the system we have in place today?
>The reason the idea came to me was then we could be ready if anyone every
>snapped in a PGP/Kerberos module or other public-key cryptosystem. The
>client could securely transmit the information. Perhaps this could be
>extended further to:
>
> #$# login username password
> %login OKAY <NAMES COUNT=3 SIZE=32>Jerky Boy,Weenie,Fingers</NAMES>
I more or less like this, tho each possible name should be inside its
own <NAME></NAME> brakcet, I think. If there is a welcome message, we
might also want to include it here or after the next one... not sure...
> #$# setup <NAME>Jerky Boy</NAME><BLURB>I'm a weenie</BLURB>
> %setup OKAY
> or
> %setup FAIL "The reason is..."
>I like '#$# setup' because it is vague enough to
>allow us to drop in other tags. We could even be really cool and stop the
>server-side per-client configuration stuff (including #$# client) and do:
>
> #$# setup <NAME>Jerky Boy</NAME><BLURB>I'm a weenie</BLURB><CLIENT NAME="CaL" VERSION="0.3.9" OPTIONS="recip_regexp,connected,sender,...">
>
>This would allow client authors to add and drop functionality without
>haggling with jerky server developers. :)
I like this a LOT. Emphasis on LOT. Possibly even have an option
negotiation so that clients can co-exist with different versions of
the server (something simple, possibly like telnets
will/won't/can/can;t).
Now to fit in wWhammy's idea... which I also liked. Can we nail down
details?
My next question turns into implementation times for all this (and the
rest of my requested features). Are we going for a target when we'll
exist with all the new features or protocols? I would like to do it
somewhat staged, even if it means I'll have to rewrite some code. I
would like to get some multi-window support into CaL, tho I think I
can mostly do it with existing protocols. The long, possibly
interrupted, output will cause me problems, but I'll cope.
What are we missing?
P