My name (as you can see from the mail header) is Eric Schult. On
lily.acm, I am known as Falcon.
Historically I am more of a unix programmer, but recently have been
learning MS-Windows application development. I'm a bit green when it
comes to MS-Windows, but nonetheless I am willing to devote some time to
a MS-Windows-based lily client, once the server-side support is available.
Since I am new, and not really a Core developer pre-se, It may seem I
am a bit nieve when it comes to lily internals. This is _not_ an
illusion, so please forgive me.
Paul Stewart writes:
[...]
| I guess all that really needs to be given is a good method of receiving
| these events in discrete units and easily classifyable categories.
Our agreement runneth over.
| In this last requirement, I don't think my last message was complete: with a
| small enhancement on the server side the whole concept of leafing becomes
| very simple. It is a special case of the already established /group
| mechanism, which describes send-group and recieve group tags that are
| requested. Here's an example:
|
| Beknownst or unbeknownst to the server, Whammy is running LilyStub,
| an application that sends him messages from each of his favorite
| categories to separate windows. He wants all his Lily-related groups
| and people (Core, lily-dev, Christian (:}), and lilpok) to be sent to
| him in one window, while all "whimsical" discussions should be placed
| in another window (whine, wank, consulting). Note carefully, although
| it wasn't stated above, messages TO lily-dev and FROM Christian are
| to be placed in the same category. In addition, Whammy would like to
| spare himself endless hours of confusion by being able to tag the
| messages he is sending out with some sort of identifier associating his
| message with the window from which it originated. An imaginary
| exchange could be:
|
| (at setup time)
|
| /lgroup new lily TO core,lily-dev,lilpok
| /lgroup lily add FROM Christian
| /lgroup new whimsy TO whine,wank,consulting
|
| This might do something along the lines of creating an entry into a
| list:
|
| #109.lgroups = {"lily", "whimsy"}
| #109.lgroups_memb = {{{#126, #127, #128}, {#102}}, {{#129,#130,#131}{}}}
|
| So, translating from a Joe Standard Lily message:
|
| -> From Prisoner [netlag], to whine:
| - I sure wish I had a net
|
| To a prototype new format:
|
| %msg public Prisoner whine whimsy : I sure wish I had a net
| ^ | | | | |
| | | | | Some sort of message start
| message | | | delimeter
| class | | Comma separated list of lgroup(s)
| | | associated with this message
| | Public message "to" list.
| "From" entity.
|
| To address the last of the issues (endless hours of confusion, etc),
| an addition to the %sendmsg would be needed. Let's assume for a
| moment that I was Prisoner .1 seconds before the above message was
| sent. Somewhere in my client I would have caused to happen:
|
| /sendmsg public whine window1 : I sure wish I had a net
| | | | |
| | | | Same as above
| message | This tag will be appended to the send ack
| class | described below.
| Target entity
|
| Now, let's assume Prisoner and Whammy, being the similar folks they
| are, use the same lgroup (saving me from having to re-create more
| silly group names). The message ack might look like:
|
| %msg public-ack Prisoner whine whimsy,window1 : (message sent to whine)
|
Ok, I understand what you're suggesting, but I'm not sure I agree with
putting this information on the server. It would seem that the
server's job is getting messages to the right client, not necessarily
the right window of the right client.
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]
%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_.
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.
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?
-- ======================================================================= Eric Schult E-Mail: eric.schult@mvision.com Market Vision Voice: 1-212-306-0357 40 Rector Street NYC 10006 Fax: 1-212-233-1430 PGP Key fingerprint = 54 25 D7 34 C6 17 BB 93 F2 99 9D 60 4A A8 E1 8B =======================================================================