>> Second, I have heard a lot about maintaining who/what lists. I think
>>this is great idea, and one I have longed to explore with lilypad. I see
>>no reason the server, at connection, cannot begin to download to the
>>client a list of who is on and there current state. Further, there is no
>>reason the server could not recognize certain types of events for certain
>>clients and transmit those as both text and event information for the
>>client.
>
>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. No one who worked directly on the code of the
Clover project had much experience with C, large scale applications, or
issues inherent in distributed systems. That is changing. In the time
since Clover was developed I think we all have matured as systems designers
and developers. As well our understanding of distributed systems
has grown in every way. To allow the failures of Clover to haunt us forever
is to end our participating in the field of CMC.
>Unfortunately - there is no real good way to get around this... at
>least not given the structure we have and the things we are trying to
>accomplish... (at least i haven't been able to think of one...)
>
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.
>> Lastly, (I'm sure people are glad to hear that) I have the following
>>suggestions for server->client information sharing:
>>
>>%who object user_name [user blurb] state onsince last_input (flags)
>>%what object disc_name disc_title created last_input flags
>>%event object event_name event_time {recips,subjects} {variant_client_info}
>
>Right on the mark... {: this is almost exactly what I've been looking
>for...
>
Great!
>My concerns are mostly nitpicky, and somewhat fall along with the
>comment above
>
How about switching to a SGML-style system?
<WHO><OBJECT><NAME></NAME><BLURB></BLURB><STATE><ONSINCE><LAST_INPUT>
<FLAGS></WHO>
>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?
>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.
>3) I'm unclear what "recips,subjects" indicates... will this be an
>object number reference?...
>
Yes.
>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.
>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.
>All solveable... but think about them... {:
>
Yep.
>> 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?
>> 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. We can continue to expand it in various ways. One
idea I have thought about more now is my old Thoth object from Lily (the
CMC I worked on before I did lily). Thoth was an Objective-C object which
acted as a protocol translator. It was then added onto to form a bunch
of descendant objects: IRC-Thoth, Clover-Thoth, and Lily-Thoth. The Lily
system as a whole communicated in a meta "language" which embodied non-
specific CMC operations (set name, rename, connect, disconnect, etc...).
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. It is fed the raw information which generates
event messages. Then the client module reformats the information and delivers
it to the client. For the telnet module maybe we add a 'waiting' feature
so that it just sends updates every n time or after you hit enter (to
avoid the bad painting problem). For lclient perhaps we format all the
messages and do pretty much what we do now. For CaL we send raw information
elements and have a serial number which is incremented when an object
pushes a change through the client module (to help keep CaL up to date).
Some more of that half-baked loaf.
later,
christian
-----
Christian A. Ratliff / Chief Technical Officer / techs@biddeford.com
(NeXTmail & MIME okay) / Designer and Co-Author / ratlifc@lily.org
http://www.biddeford.com/~ratlifc/