> 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).
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...)
> 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...
My concerns are mostly nitpicky, and somewhat fall along with the
comment above
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...
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 even information).
3) I'm unclear what "recips,subjects" indicates... will this be an
object number reference?...
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?...)
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?...)
All solveable... but think about them... {:
> 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...)
> 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.
>christian
>
>
>-----
>Christian A. Ratliff
>Work: <ratlifc@ctron.com> (NeXTmail and MIME okay)
><a href="http://indikos/~ratlifc">Cabletron Home Page</a>
>Home: <ratlifc@biddeford.com>
><a href="http://www.biddeford.com/~ratlifc/">External Home Page</a>
P