[lilycore-dev] What to do, what to do.

[Will C. <wi...@co...>]

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