First, for events (what you call status messages) the task_id() is a
pretty good mechanism. Are we sure we need to attach a serial number
to every attribute, though? That is going to get REALLY expensive unless
it occurs at a much deeper (MOO) layer. Any thoughts here?
>>>> 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>
>
Agreed here.
><ONSINCE TIMEFORMAT="how is this formatted">whatever</ONSINCE>
>
How about epoch time rather than get into formatting?
>>>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...
>
Yeah. Again I think protocol versioning or TNVT-style Will/Won't Do/Don't
is a good plan for attacking this particular problem.
>>>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?
>
Yes. I will probably give out integer object number references just so
database handles don't risk staling.
>>>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?
>
This is a good question. I really want to avoid having to chat constantly
if at all possible. Perhaps we can have a "I'm interested in all events
for the following objects" list held in each client object (attached to
each user). Otherwise we don't bother. I think the key hear is to
perceive lily as a warehouse for a veritable ocean of information and it
is the role of the client to make it easier for the user to cope with
this. Otherwise we are back to IRC-standards.
>
> [database query stuff deleted]
>
>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...
>
The problem is that you will never know all the fields in the database
unless we also come up with a schema (view) transfer protocol as well.
>> 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.
>
Yeah. I would like to (again) redesign lily to be more of an effective
object hierarchy, and building a nice client (filter) object goes hand-
in-hand with that idea.
>
>>>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?
>
I assume this will be a different style entirely. Old clients will, of
course, still have to work the same way they do now.
>>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...
>
I was thinking of the commas being easier to parse, but it doesn't
make a whole lot of difference to me.
>> #$# 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).
>
Right. The TNVT idea is a good one!
>
>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.
>
I have no idea. :)
>What are we missing?
>
People. :) We lack the necessary work-force to get going on this
effectively. There are lots of things lily needs right now and this is
just one of them. Know anyone who wants to work on the Web site, write
/help stuff, do release testing, be a server developer, be a client
developer?
christian
---------
Christian Ratliff / "Dead mice
<ratlifc@lily.org> \ have no entertainment value"
NeXTmail & MIME okay /
http://www.lily.org/~ratlifc \ - Ancient Cat Proverb