lilycore-dev Mailing List for lilycore (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

This was fixed on RPI core recently.

An experimental wiki is now in place at:

http://www.freegroups.org/lily-twiki/bin/view/Lily/WebHome

Thanks to Chris Masto for setting this up...

--
Will "Coke" Coleda                                    will at coleda 
dot com

There is a rather large list of projects that is floating about in 
several locations. Here is a first pass at briefly summarizing the 
list. If your pet project isn't here, check in Jitterbug [1] and on 
SourceForge [2]. If it's not there either, ping the list.

These are in no particular order, although the first three are very 
critical in terms of bringing other developers on board. Expect more 
emails on these three items. Once these are hashed out, then we'll be 
in a position to deal with the rest of the list.

If you'd like to claim one of these projects to work on a design, ping 
the list. Again, nothing will be accomplished without your involvement.

2.8.0:
	2.8.0 needs to be cut, so future development has a base from which to 
start. While I will defer to Garance@RPI on the particulars, I think 
it's crucial this happens sooner than later. Garance has already done a 
HUGE amount of work on this integration (thanks again!)

METHODOLOGY:
	A path for people to follow when going about development without 
having to stop and ask for directions would be a good thing.

CVS:
	To help reduce the technical barriers to a distributed development 
effort, we need a way to get a deconstruct a lilyDB into CVS, and a way 
to reconstruct a CVS checkout into a lilyDB. Garance@RPI already has a 
large chunk of this done in ruby. (And Josh@RPI has a different version 
in perl). Not having a way to easily merge code has been a technical 
barrier to contribution, and is a big reason why the various core 
branches have never fully been merged. (until 2.8.0).

SLCP:
	SLCP is incomplete. The holes in the protocol should be identified and 
filled. It should be possible for an SLCP client to never issue a / 
command (or, flip it around:  the output of each /-command should be 
(able to be) agent specific.) A way to deal with versions of the 
protocol would be helpful.

GROUPS:
	Groups should be first class objects.

GAMES:
	The game interface needs to be gutted and rethunk.

BOTS:
	Server side bots should be considered. They should be compared and 
contrasted with both GAMES and their client-side brethren.

WEB INTERFACE:
	The static views that are available need to be cleaned up, it would be 
nice to provide a stupidlily-like interface in the core.

DOCUMENTATION:
	Whenever a new feature is suggested, it is often summarily rejected 
(not by me, mind you. =-) as being contrary to the "design goals". A 
very brief summary of these goals is (a) support telnet, (b) allow 
users to protect themselves from other, malicious users. It might be 
helpful to have a more canonical list of what is typically referred to 
here to provide a >>historical<< context to view new features in. 
(Perhaps RPI-centric might be a better word there - for better or 
worse, a lot of code hasn't been written because it wouldn't get into 
RPI. This should not stop someone from implementing something for their 
corporate core and folding it back into the mainline. $setup exists for 
a reason.)

HELP:
	The help system needs to be redone to allow for real cross references, 
a consistant way of providing usage, and to eliminate "yet another 
storage mechanism".

SECURITY:
	We should be able to connect to the server securely, without the need 
for an external process. It would be nice to know if the user you were 
speaking to was also connected securely.

USERS:
	There should be a way to recycle a user's account on the core.

FINGER:
	The current system is limited. Fields should be easily added by (at 
least) the administrators.

AUTHENTICATION:
	There should be pluggable authentication modules. We are currently 
storing everything in lily. e.g., Dan Cohn wrote a patch to allow the 
server to proxy the auth request to a pop server. LDAP would also be 
nice.

JABBER:
	It would be nice if the jabber support worked (see CLEANUP)

TESTING:
	Regression tests good. It would also be nice to have code coverage 
analysis.

CLEANUP:
	All the code that isn't currently used should be removed from the 
core. (It should be checked into cvs first, so we don't lose it, then 
removed from cvs-current). Someone needs to read the historic 
documentation of the server's design, dig into the current guts, and 
come up with a refactoring plan that (a) simplifies future maintenance, 
and (b) document it, so we don't have to do this again soon. Even if 
you only come up with a partial refactoring plan, that's good. (in 
fact, it's probably better. Less stuff to change at once.)

BUG REPORTS:
	We should move from using jitterbug as our primary store for bugs to 
using sourceforge. This includes updating /submit and moving any 
existing bugs. (though it would be nice if they were closed so we 
didn't have to bother. =-)

BUG REPORTS:
	All the bugs should be prioritized. A senior developer should annotate 
the calls so that new developers can more easily get their feet wet. 
Eventually, it'd be nice if they were all closed, too!

UNICODE: (I need　コーヒー)
	Lily should be able to handle more than 7 bits. A modicum of care must 
be taken on how to deal with the "dumb" clients.

SLCP-REVIEW:
	Or, at least, SLCP-like review.

CTCP:
	A standardized mechanism for clients wishing to talk to each other 
directly. The server should provide a mechanism to initiate the 
contact, and future interaction will occur directly between the 
clients. Clients that don't register as CTCP aware should not be 
bothered.

[1] http://www.centauri.org/cgi-bin/lily
[2] http://sourceforge.net/projects/lilycore/
--
Will "Coke" Coleda                                    will at coleda 
dot com

It's been a while since this list has been used for anything other than 
reporting bug fixes. Enjoy!

There's been a lot of talk on the RPI core in the past week about 
server development, lack thereof, and how hard it is to get anything 
done with "the server". I completely agree. There are technical 
barriers to entry. There are social barriers to contribution. We're 
(note: not /I'm/) going to mitigate as many of the issues as possible, 
leaving folks with the ability to actually contribute in a useful 
fashion as their time and skills permit. I must stress, however, that I 
plan on writing very little code to fulfill this prophecy. So far, in 
all the discussion I've seen one person say they'd contribute if we 
provided some infrastructure tools. So, here's hoping they deliver. =-)

(And please, gentle reader, before you say, "but there's more to 
development than coding", I know. I know. See followup emails for more 
details, and for the meantime, curb your pedantry.)

My laissez faire attitude has been (easily) misinterpreted as "no, we 
ain't doing that", which, ironically, is exactly the thing I was trying 
to avoid. In my effort to get out of the way, everyone seems to think I 
took the road with me. I'll attempt to fix that by putting up some very 
large green signs, and we'll see if anyone follows them.

BTW, anyone who is NOT on the RPI core [1], and is interested in doing 
development work, I apologize: there's been an even larger barrier to 
entry for you since we haven't been using the other online methods of 
communication available to us, just RPI core.  If you're not on RPI 
core and wish to contribute, by all means, join the mailing list, drop 
us a line, or request an account on the RPI core [2], and join us in 
the -lily-dev discussion.

** WHO WE ARE

Coke@RPI:

Christian@RPI is the primary architect. My job description used to be 
"thorn in Christian's side". Sadly, that's no longer an option. Since 
he retired, I'm more of a project manager, though I've not had many 
resources to manage.

Garance@RPI :

Garance is pumpking [3] for the 2.8.0 release. Also the person who owns 
the server RPI's core runs on.

Wakko@RPI:

In charge of the documentation.

Others:

Folks that are currently attributed to a problem report, at least 
according to Jitterbug [4]. Nautilus@RPI, Transparent@RPI, Ach@RPI, 
Christian@RPI. There are all the client developers, and the peanut 
gallery in -lily-dev@RPI. I apologize profusely if you're in the middle 
of some server work and I missed you. Please drop the list a line to 
let me know what you're up to.

** THEN

In the beginning, the production core at RPI was patched on the fly, 
and it was good.

In the middle, a devCore was created. Most development took place here, 
though some still happened at RPI. Cores were painstaking carved from 
the handcrafted devCore.

Near the end, our primary architect did a large amount of development 
taking a stock 2.6.4 core, fixing lots of bugs, adding lots of feaures, 
and providing the release to the community, to be integrated by the 
pumpking. (who, at the time, was Coke@RPI)

** NOW

This didn't happen (it was originally hoped that this would occur by 
the end of 2002). I got sidetracked, for both technical and social 
reasons. Garance@RPI thankfully pulled up the slack and is working on 
integrating RPI, devCore, and Christian@RPI's final dev copy. 
(Christian's did a substantial amount of development against a stock 
2.6.4 release)

Garance is, SFAIK, mostly done with this integration work. The 
outstanding issues include a few high priority jitterbug tickets, and 
help. Garance's work here will be used as the 2.8.0 cut.

Kudos to Garance for doing this much needed integration work.

** LATER

Although lily is a mature project, there is still work to do. However, 
once a project becomes "mature", there is a palpable amount of inertia. 
Things work (mostly).

I think one of the other biggest recent problems is a rather circular 
problem of "lack of volunteers" and "lack of direction". Given that 
lily is staffed by volunteers (who typically have other projects on 
their plate), there's a definite concern about investing cycles on 
potentially useless tasks. So, they may not bother writing up a list of 
things to be working on, or design notes, because there are no 
volunteers to implement them anyway, but instead hack on a particular 
bit of low hanging fruit, or fix a particularly shiny bug.

On the other hand, potential volunteers may be looking for work to do, 
but given a lack of direction, generally wander off, or don't speak up. 
( Not to mention lily's history of burning out contributers, which I'm 
sure it shares with other projects. ) Client developers, coming in from 
the side, occasionally have very good requests for updates which can 
easily fall by the wayside in large part for the reasons described here.

In the interests of furthering my secret plan, and breaking the 
apparent deadlock here, I'll present a roadmap of sorts over the next 
few emails. I stress: if you're really interested in lily server 
development, you're going to have to do some of the work. Hopefully 
we'll make that easy for you to do.

My next email be a partial listing of outstanding projects. I will 
followup with notes on a few of the most important items, all of which 
will be geared towards making work on the remaining issues 
distributable to those interested in working on them.

~Coke@RPI

[1] http://rpi.lily.org:7780
[2] http://rpi.lily.org:7780/new/
[3] http://www.nightflight.com/foldoc-bin/foldoc.cgi?pumpkin
[4] http://www.centauri.org/cgi-bin/lily
--
Will "Coke" Coleda                                    will at coleda 
dot com

This is available on RPI core as:

/what moderated by kazrak
/what authored by kazrak

> Full_Name: Brad "Kazrak" Jones
> Lily_Core: lilyCore 2.3; MOO 1.8.0r5
> client: 
> OS: 
> Submission from: (NULL) (24.93.152.147)
> 
> 
> Feature request: an option on /what or /where that will show only discussions
> that one is a moderator/author for.  (As an added feature, have it support
> arbitrary users.)  '/what moderator <username>', '/what author <username>'
> perhaps (parallel to '/what joined'.
> 
> 

Done.

Enjoy!

> User: [#1294] dec
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Fri Mar 15 13:26:24 2002 EST
> ---%report%----
> It would be usefull to be able to "/review rpi,capdist today"
> ---%report%----
> 
> 

/review discussion today match http

works, as does the slightly more useful (in this context)

/review discussion today url

> User: [#412] jyri
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Thu Sep  6 09:47:31 2001 EDT
> ---%report%----
> It would be useful if you could '/review discussion today grep http' and
> return only the events that contain what you grep.  Originally I thought
> about a feature just to review URLs, but if it were a full-scale grep
> feature it would be very neat.  So many times I have tried to find something
> in a review where I actually did have a word or two I could have used.
> ---%report%----
> 
> 

Done, spelled:

/review -random last 10e

However, my implementation is that this shows (at most) YOUR last 10 events.

Counting the events is the last thing that's done to the list.

You can even do:

/review rant,ranttalk last 42e

Regards.

> User: [#829] sdn
> MOO: 1.8.0r5
> Core: lily running rev 2.3
> Server Time: Thu Nov 30 14:09:46 2000 EST
> ---%report%----
> "/review <something> last <n>" would display the last <n> events in 
> <something>". Example: "/review random last 10" would display the last 10
> events from -random. 
> 
> I think this would be an AND-type operation, as other /review options, not
> a final filter. So: "/review random user sue last 10" would display any
> events in -random from Sue D. Nymme in the final ten events, if any; not
> the final ten events from Sue D. Nymme in -random. But hey, whichever's
> easier to implement.
> 
> The benefit to this feature would be for reviewing recent events in high-
> traffic discussions, where "/review -foo today" results in way too many
> events.
> 
> Thanks,
> Sue D. Nymme
> ---%report%----
> 
> 

> User: [#127] coke
> MOO: 1.8.0r5
> Core: lily running rev 2.3
> Server Time: Thu Nov 30 10:52:36 2000 EST
> ---%report%----
> p -> (10:51) From Achorrath, to lily-dev:
>  -  Unfortunately, /review set and /review mark never made it here.
> 
>  -> (10:51) From Achorrath, to lily-dev:
>  -  I'm sure I still have the source code archived somewhere. It's asked for
>  - enough that I should dig it out.

This did eventually make it to RPI at some point.

> Achorrath;yes, you should. =-)
>>> (10:52) Private message from Prisoner, to Achorrath, Coke:
> - or   /review last 5m... or /review -limit=20... or... {:

/review last 5m

and 

/review last 5e

now both work on RPI.

> ---%report%----
> 
> 

This works, and is spelled:

/review event private from me to prisoner

though in practicality, that can probably be as short as:

/review to prisoner

> User: [#127] coke
> MOO: 1.8.0r5
> Core: lily running rev 2.3
> Server Time: Mon Nov  6 11:23:44 2000 EST
> ---%report%----
> It would be nice if you could review events based on the -target- user,
> so that 
> 
> /rev event private user me target prisoner
> 
> /why
> would show all sends that I sent to prisoner. 
> 
> ---%report%----
> 
> 

> Full_Name: Jyri Palm
> Lily_Core: 2.3
> client: unix
> OS: Solaris
> Submission from: (NULL) (24.161.43.60)
> 
> 
> It would be nice to expand the /review capabilities.  Sometimes someone will
> comment on something from way back where the context would be helpful, and
you
> remember a keyword.  The problem is that 500 lines may have passed.
> 
> Thus: '/review discussion keyword foo'

This is spelled

/review discussion match foo

where foo is a MOO regular expression.

> There should be the option to see events with the keyword (let's say you are
> just looking for 'http') or to start a review at the keyword (so you can
follow
> a particular discussion).

since you mention http specifically...

/review discussion url

will grab anything that looks like a url and format it to make CNP easy.

> Of course, being able to review at a specific start time would be helpful. 
But
> more than that, if you could say '/review all 13:00' and it would pick up all
> events from discussions you are currently a member of from the start time. 
> Among other things, this could be useful if your review buffer overflows. 
When
> this happens the only recourse is to /review discussions individually, and
yet
> all the data still exists, just not your perception of it.  You also miss the
> discussion crossover moments.

/review disc1,disc2,disc3,...,discN <options>

now works for N<=20. (to support an arbitrary size, we'd need to completely redo
the way review is stored.)

> Alternately, of course, a scheme that mails your review buffer to you when it
> reaches the limit would probably work better, or be easier to implement. 

This isn't done. If you reeeeally want this, please resubmit it as a separate
bug.

Again, fixed on RPI.

The message now is:

/quit osx
(you have quit osx)
-osx;test
(you are not a member of osx)

And, it wasn't me. =-)

Regards.

> User: [#121] prisoner
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Tue May  8 08:17:00 2001 EDT
> ---%report%----
> Send location matching gives confusing results if not discussion member - part
2
> -nrg,-train;test
> (could find no discussion to match to "nrg")
> (could find no discussion to match to "train")
> 
> 
> And yet the discussions exist, but I'm not a member of them.
> ---%report%----
> 
> 

This appears to be fixed on RPI core.

I didn't do it. =-)

Regards.

> User: [#121] prisoner
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Tue May  8 08:16:00 2001 EDT
> ---%report%----
> nrg,train;<whatever>
> (could find no user to match to "nrg")
> (could find no user to match to "train")
> 
> While it was true there were no users, there were two discussions that
> exactly matched that I was not a member of.
> ---%report%----
> 
> 

This is a duplicate of PR#563.

Fixed on RPI core.

Thank you for your report.bug report

> User: [#3163] n
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Tue Mar 18 16:41:03 2003 EST
> ---%report%----
> 3921 </ignore> (you are currently ignoring FeRD {privately and publicly},
Maker
> {in lily-dev}, notFish. {in random}, Steve {in lily-dev} and being ignored by
> FeRD {privately}, damien {privately adamiend publicly}, Almohada {privately
> aAlmohadad publicly})~0D~0A~0D~0AMy name is "n", it appears that in the code
> that generates "ignored by" it is substituting any occurrences of my name for
> the source's name, i.e. "privately a_n_d publicly" -> "privately a_damien_d
> publicly"
> ---%report%----
> 
> 

Christian forgot that he had /block'd that discussion.

closing call.

> User: [#112] cratliff
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Thu Dec 19 14:26:41 2002 EST
> ---%report%----
> I am currently a member of two private discussions, issuing the "/WHAT
> joined" command only shows me one of them. I am in no other discussions
> but these two, so the absence is easily noted.
> 
> christian
> ---%report%----
> 
> 

>>>>> "Christian" =3D=3D Christian Ratliff <lil...@ce...> writes:

Christian> Jack, The behaviour you describe is by design. When you are
Christian> depermitted from a discussion, it ceases to exist for
Christian> you. For that reason a destroy notification is the most
Christian> accurate representation of what occured.=20

This is not completely true.  If the discussion were truly destroyed,
then a discussion of the same name could be created immediately
thereafter.  If a user is de-permitted, they are told the discussion
has been destroyed, which is a little white lie -- it still exists,
and this existence can be validated by attempting to re-create it.
It's my personal opinion that lily's attempt to be polite fails in
this instance.

Christian> If you are permitted to a private discussion, or your ban
Christian> is lifted from a public discussion, then a permit event is
Christian> also the best description of what took place since the
Christian> discussion is not, in fact, newly created.

From=20the perspective of the re-permitted user, it is indeed created.
It did not exist before, and it now exists, so that implies a create
event, by the logic used in the previous instance.  Since the
discussion was in existence the entire time, a permit event makes more
sense here, I agree.  But you can't have it both ways and be
consistent.

Christian> While one could easily argue at length that a depermit
Christian> should make clear to a user they have been kicked out, such
Christian> is not the design of lily.=20

In my humble opinion, while this may have been appropriate for the
instance of lily at RPI at the time lily was designed, I do not think
it is necessarily appropriate for all other instances of lily.  It is
also not clearly documented and confuses even regular users when they
attempt to write clients.  If this is to continue being a feature of
lily, perhaps emphasizing it in the appropriate parts of the
documentation may help.

Christian> The point remains, nonetheless entirely valid, and for a
Christian> different CMC the solution proposed here may be quite
Christian> applicable. A good idea remains a good idea even if it does
Christian> not fit within the current design criteria.

I'd love to see a complete list of those criteria.

Christian> christian

Jack.
(I bet you wouldn't mind a complete list of those criteria yourself.)
=2D-=20
Jack Twilley
jmt at twilley dot org
http colon slash slash www dot twilley dot org slash tilde jmt slash

Jack,

  It is embarrassing to provide the same pat answer twice in a row to what are
clearly well thought out defect reports, but I must do so. The behavior you
describe is entirely by design in lily because of how the permissions structure
operates. If I am going to take a public discussion private, then it is crucial
for me to be able to note those users who should retain access during that
transition. The mechanism for that is to permit users explicitly to the
discussion.
  Again, though you could argue this issue at length lily operates this way by
virtue of its design. Deven Corzine, in Phoenix, chose a different approach, and
his mechanism is very much like what you describe. Once more a good idea remains
a good idea, and your point is well taken.

christian

> User: [#157] nautilus
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Wed Nov 13 15:55:59 2002 EST
> ---%report%----
> /permit <user> <public discussion> should simply remove the user from the
> list of depermitted users.  Similarly, /depermit <user> <private discussion>
> should remove the user from the list of permitted users.
> ---%report%----
> 
> 

Jack,

  The behaviour you describe is by design. When you are depermitted from a
discussion, it ceases to exist for you. For that reason a destroy notification
is the most accurate representation of what occured. If you are permitted to a
private discussion, or your ban is lifted from a public discussion, then a
permit event is also the best description of what took place since the
discussion is not, in fact, newly created.
  While one could easily argue at length that a depermit should make clear to a
user they have been kicked out, such is not the design of lily. The point
remains, nonetheless entirely valid, and for a different CMC the solution
proposed here may be quite applicable. A good idea remains a good idea even if
it does not fit within the current design criteria.

christian

> User: [#157] nautilus
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Fri Nov 15 16:00:56 2002 EST
> ---%report%----
> A discussion which is not joined by a user and is then depermitted
> to that user causes a "destroy" event to be sent.  When this discussion
> is then repermitted, a "permit" event is sent.  This is broken as either
> both create and destroy or permit and depermit should be used, not mix
> and match.  
> ---%report%----
> 
> 

This has been fixed in RPI core in the release candidate for 2.8.0

Thanks for the report!

Will,

  This has been fixed by changing the indentation of /GROUP. 

/GR                                                                            
Group      Members                                                             
-----      -------                                                             
FOO        Christian, Christian, Christian, Christian, Christian,
           Christian, Christian, Christian, etc...

christian                                                                 

> User: [#127] coke
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Wed Nov 21 13:53:08 2001 EST
> ---%report%----
> There needs to be some kind of separation between groups. perhaps wrap
> everything in ()'s ?
> ---%report%----
> 
> 

Dave,

  Thanks for reporting this problem. I looked into it for a few minutes, and I
believe this is a bug in the client software you are using rather than in the
server itself. I seem to recall at least one client recently adding support for
intercepting the /OOPS command to reset their ";" expansion.  

christian

> User: [#3223] daveh
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Sat Nov 17 12:44:18 2001 EST
> ---%report%----
> If I send something to -foo, and then /oops -bar, I expect that my next send
> using ; will go to -bar, when instead it goes to -foo... which means I need
to
> /oops again.  In other words, I expect /oops to work like a send, and not like
a
> command.
> ---%report%----
> 
> 

Allen,

  This message has been fully documented. I have included in it a note
describing the problem with logged out users being in the MEMBERS attribute for
a group.

christian

> User: [#121] prisoner
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Sun Aug 11 11:58:03 2002 EDT
> ---%report%----
> With
>   #$# options +leaf-notify
> enabled, the server sends a number of lines such as
>   %GROUP NAME=3=foo MEMBERS=4=#121
> after all the %DISC messages.  This message is not defined in
>   http://lilycore.sourceforge.net/Simple%20lily%20Client%20Protocol.html
> ---%report%----
> 
> 

Allen,

  This has been fixed with the following language:

One cornerstone of SLCP is the variable length string. The format
is '<kbd>ATTRIBUTE=n=STRING</kbd>', where <kbd>n</kbd> indicates
the length of such a string. Though the attribute names are usually
described in uppercase, they can appear in the protocol in any case.
The rules for when a string is to be length prefixed are as follows:
<ul>
<li>If the string is directly user controlled, then it <b>MUST</b>
    be prefixed.
<li>If the string is from a set which the server administrator can
    control, then it <b>MUST</b> be prefixed.
<li>If the string is designed for direct display to the user, then
    it <b>MUST</b> be prefixed.
<li>If the string serializes a list of arbitrary length, regardless
    of whether the delimiter is know, then it <b>MUST</b> be prefixed.
<br>
<li>If the value is an integer, float, or object number, then it
    should not be prefixed.
<li>If the value is a string specified by the protocol itself, then
    it should not be prefixed (i.e. EVENT=eventname).
</ul>
If you should ever notice an attribute which fails to conform to
these rules, please report it as an URGENT bug immediately. It
is most certainly a mistake.<p>

christian

> User: [#121] prisoner
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Sun Aug 11 10:14:03 2002 EDT
> ---%report%----
> The documentation for SLCP at
>   http://lilycore.sourceforge.net/Simple%20lily%20Client%20Protocol.html
> documents that strings with a length attribute are good, and documents
> their precise use.  In command documentation, however, it illustrates
> strings without a length attribute (for example, the %USER STATE 
> attribute).
> Please clarify the documentation about the following:
> - When can/will/may/must length-free variables be used?
> - What flexability do parsers have in interpreting fields?  Should/must
>   they allow length-free attributes when the spec has illustrated it
>   with a length and vice-versa?
> - What flexability do generators have in creating fields?  Must they
>   use the exact format given, can they be flexible in using "best
>   judgement" for when to use length and when not, or should they always
>   use length for non-numeric data?
> 
> ---%report%----
> 
> 

Allen,

  A reference to the '%DATA NAME=events' message has been added. The broken link
was already fixed at some previous point. This content will be published later
today.

christian

> User: [#121] prisoner
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Sun Aug 11 11:58:06 2002 EDT
> ---%report%----
> The page
>   http://lilycore.sourceforge.net/Simple%20lily%20Client%20Protocol.html
> in the %NOTIFY section, under the EVENT parameter indicates that 
>   A command, which has not yet been designed, will inform the client 
>   of all events.
> Yet the "%DATA NAME=events" message appears to do so.
> Additionally, the documentation at that same URL advises to
>   Please see the <a href="events.htm">event documentation</a>
> Yet there is apparently no file "events.htm", nor "events.html", nor
> "event.htm", nor "event.html".
> ---%report%----
> 
> 

Allen,

  This has been corrected in the docs. The time is indeed UTC, and it was only
my personal foolishness which resulted in the incorrect docs. The updated docs
will be published later today.

christian

> User: [#121] prisoner
> MOO: 1.8.1+g1+s
> Core: lily running rev 2.6.2
> Server Time: Sun Aug 11 11:06:10 2002 EDT
> ---%report%----
> The SLCP documenation at
>   http://lilycore.sourceforge.net/Simple%20lily%20Client%20Protocol.html
> says
>   unix_time is the Unix-style time on the server, 
>   <em>in the local timezone!</em> 
> which contradicts this conversation on lily
>   ### It is now Sat Aug 10, 2002 ###
>   
>   -> (00:09) From (), to lily-dev:
>   - The time sent from the lily-server is not UTC, it's lily-server time sent

>   - from the Jan 1st 1970 00:00 local lily server time?
>   
>   -> (00:11) From Kazrak, to lily-dev:
>   - In SLCP, the time sent is a Unix time_t, which is UTC-based.
>   
>   -> (00:11) From (), to lily-dev:
>   - So you see the timezone in AZ not NY?
>   
>   -> (00:12) From Kazrak, to lily-dev:
>   - Correct.  It's up to the client to handle it intelligently.  (Which is, 
>   - fortunately, fairly easy to do.)
>   
>   -> (00:12) From (), to lily-dev:
>   - Yeah... if it's in UTC, it is ;)
>   
>   -> (00:13) From Kazrak, to lily-dev:
>   - In tlily's case, it just hands the timestamp to localtime(), I believe.  
>   - I'd assume most clients do the equivalent in their languages' libraries.
>   
>   -> (00:14) From (), to lily-dev:
>   - cool :)
> 
> Please clarify.
> 
> 
> ---%report%----
> 
> 

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec
2002	Jan	Feb (9)	Mar	Apr	May	Jun	Jul	Aug (2)	Sep	Oct (17)	Nov (2)	Dec (2)
2003	Jan	Feb	Mar (9)	Apr (1)	May	Jun	Jul	Aug (3)	Sep	Oct	Nov	Dec
2004	Jan (1)	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov (1)	Dec (1)
2005	Jan	Feb	Mar (4)	Apr	May (2)	Jun (2)	Jul (3)	Aug (2)	Sep (6)	Oct (6)	Nov	Dec
2006	Jan	Feb (1)	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

lilycore-dev Mailing List for lilycore (Page 2)

lilycore-dev — The development of the lilyCore project will be discussed here.