Doug Engelbart's I N V I S I B L E R E V O L U T I O N
HyperScope for Invisible Revolution | Stage 1 Spec
The way the email to blog (RSS) would work is (in principle) simple. User emails a bunch of text to an email account (theirname@cynapse.org) and it gets posted on the web (http://theirname.cynapse.org).There is one admin page for the user. The user gets there by logging on (simple dialog box asking for username and password) to http://theirname.cynapse.org/admin
On that page they can see all posts and delete posts. They can also choose a template for how their page should look. The template is a collection of HTML pages with <--body and such server-side tags to indicate what should go where. The reason the template is a collection of pages and not one is so that we can easily describe the look of the post itself and separately the page it is on and later even a frame set. For now though, this is just something to keep in mind, a simple start page would do.
INPUT
OUTPUT : WEB WEB
The page template would include <Head> information as well as the formating line and refer to how the posts should be listed with a single <--post comment. It could include CSS info and whatever.
Each blog page will be a collection of posts with added controls, as detailed in 'Email parsing' above. There will also be a full page worth of <BR> at the end, to ensure that anchors can pull pages all the way up.web template notes
A NOTE ON CODING Note for Mikhail:
There is one thing which is very important with the email to rss & html system which I have not pointed out yet, but which you were likely to do anyway.
It's very important that the code which covers the input of the emails, the parsing, the storing of internal XML versions of the post, the XML to RSS conversion and the XML to HTML conversions (with it's attendant display settings) are very separate. I'm sure the list I wrote it here is not functionally correct, but the point is that hopefully it'll be relatively easy to focus on only one component of the whole flow.
This is bearing in mind expected bugs in the system in general, and particular growth of the internal XML structure which will come to take on all the features of Augment plus more, as well as the HTML view specification service, which is not intended to exist in the first version at all, but should ideally be able to plug into the HTML generation.
Now, you are also completely free to reject all of this and get a simple system together as a learning exercise for all of us. You are the head developer and it's up to your judgment. I just need to know how this is coming together internally.