Some background first. Under CONNECT, info was implemented as a file that was stored in the MTS account that was attached to your CONNECT account. CONNECT itself had no info editing facilities. The file was limited to a certain size for UI issues. Space issues were enforced by MTS itself, of course.

When we moved to Clover, many things that MTS took care of for us had to be done inside Clover. This included management of the info file. The line limit was preserved.

When we moved to lily, this was maintained, and expanded to include memos as well.

Once we expanded to this point, some problems in the system began to show through:

• An editor was created, but it was extremely limited. The basic clients do not realize you're editing, and will show output while you are entering a memo. There is also no version control and very poor editing facilities (limited to appending). Pasting into this editor is nasty since clients handle tabs weird - this is a common problem.
• Out of self preservation, the lily server implements a storage limit on total memo size. This has largely replaced the line limit, since it was more important to represent multi-line data.
• Discussions that are destroyed lose their memos.
• Lily is a great conversation system. It is a lousy document management system.

Simple usage has also illustrated some impracticalities:

• Many discussions map directly to a website, but there is no easy way to put information on the website and the memos at the same time.
• People tend to use URLs instead of memos in many cases. Many memos are now just lists of links.

The proposal is simple:

• Info and memos should not be stored as part of lily itself.
• Instead, lily would store URLs to these things.
• While clients can access the URLs, the /info or /memo commands can be used the same way as it is today to read them.
• Users can set URLs to infos and memos.
• If we wish, we could also create a component that stores memos using the same commands they do today.

To emphasize - users should not need to see anything different from today unless they want to take advantage of the new features.

These changes give us the following:

• Memos are no longer stored in the lily database. This can save some core space.
• Similarly, users are no longer limited by the filespace the core provides - they can use their own space as they see best fit.
• Users can edit their memos in a variety of ways, depending on what meets their needs best. For example, memos for a discussion could be managed through a wiki if that makes the most sense.
• Memos can be dynamic by having its URL point to a dynamically generated page. This can replace some current uses of bots.
• Discussions related to websites can update documents once, on the website, and have it automatically reflected in the discussion. (The converse is currently true, more or less.)
• Clients that are URL aware can take advantage of this. Clients that are not do not change.

---

My suggestions for specific extensions to implement this:

• add a new command to /memo, "seturl":

/memo seturl [discname|username] tagname

This would tag the particular memo as a url rather than plain text and store the url. I'm not familiar with the storage of memos, so I can't say how hard it would be to save this tag; my uninformed guess is that it isn't that difficult.

• when the particular memo is displayed using /memo, an in-server http client is called to access the url and the contents are displayed directly. I have a basic moo http client (adapted from moo.ca) that could be used for this purpose.

The direct display of the url contents is a bit limiting but would get us halfway there. The next step would be to add in a simple html renderer to convert text/html items to plaintext with minimal formatting, or to allow clients to request the raw html directly if they specify that they are able to handle such.

-- JeffR - 22 Dec 2005
to top