The major reason for having this activity on the server is because only
the server (at this point) has enough state info to pull this off without
a lot of duplication of information, and synchronization. In even more
complex clients this might be necessary, but forcing it on the smallest
common denominator isn't wise, in my point of view.
> I would suggest a method less tied to the server or windows, and make
> it more generic.
>
> [similar /lgroup setup (possably dialog-box-oriented, etc etc) but
> its effects are completely local]
However if this /lgroup setup is done on the client, the client needs to
know about all existent users, discussions, etc. This isn't just a one
time thing. It needs to know if discussions are renamed, if people rename
themselves, etc. The server-side algorithm works by object number (which
isn't accessible by normal users; perhaps that's what you want?), so it's
better at tracking changes in discussion membership and naming.
>
> %msg public Prisoner whine <ack-code> : I sure wish I had a net
>
> where the parameters are identical except for <ack-code>, which is
> some _disposable_ tag the client assigns (probably some counter or
> something) whose scope is _exactly_one_message_.
>
Is the above code supposed to be a "/sendmsg" (by the conventions that I
was using in my message)? The "window1" in my message would have been
held only for the duration of the message delivery. Perhaps I didn't
state that clearly before.
> The server would then ack with...
>
> %msg public-ack <ack-code>
> or
> %msg public-nak <ack-code> <error#> <error-arg1> <error-arg2>
>
> Providing minimal processing on the part of the server and client (and
> network).
>
> Assuming that the client knows from which window the request came
> from, it can route the ack accordingly, and can generate the "Message sent
> to..." in the vernacular of the client UI. The scope of the ack-code is
> that one message, so the server need not store it at all.
>
The inclusion of the original acknowledgement message prevents the client
from necessarily keeping up with the (quickly changing, at times)
different sorts of conditions that you can get involved in. In addition,
this would require the client to know how to expand usernames, as the
client isn't told necessarily where the message ended up going (this is
especially significant in the cases of /groups, where the client
definitely wouldn't know, unless and until there is significant
infrastructure available for continuous state transferral, and the client
is sophisticated to make use of that information).
> In short, I'm of the mindset to have the server support
> multi-threaded/multi-window operations, but I don't see why it shoul
> have to process anthing more than necessary, so as to not overload the
> server.
>
> Paul, have I missed your point? Is there something I've left out?
My mindset is that the server should be able to support a range of
different modes of operation. Both of our mindsets have advantages and
disadvantages, a couple of which I'll point out here.
Server-based grouping:
Advantages:
* Simple design
Disadvantages:
* More code and space in the player's object used for holding lgroups.
Client-based grouping:
Advantages:
* "One stop shopping", in the extent that all the information for
grouping, sending, etc is held in the client. With the information
it needs, the client should be able to go as far as catch sending
errors.
* Does not require the player object to hold any more info.
Disadvantages:
* Significantly more sophisticated code used for either syncronization,
or significant system throughput consumed by repeated stated
transferrals.
* Client design becomes more complex.
* The client will either not be able to hold group information between
sessions, or some standard will need to be made for holding that
information between invocations of the program (and perhaps between
different clients?)
* Client developer needs to know more about the internal workings of
the Lily server in order to simulate and duplicate its functionality.
Let me re-iterate: I think that both models are valid, and I feel that
both of them can be supported elegantly under the infrastructure. I think
the first design is an easier start for developers that don't (yet) want
to go whole hog into duplicating the Lily database, and requires, in the
larger spectrum, a smaller amount of traffic.
-- Paul