FutureFeatures - DemeWiki

Email interaction: should be able to reply to a POD Notifier message but (1) reply to the person who sent the message, and (2) actually post to the forum.

This is very difficult because SMTP has no authentication. Quicktopic for example lets you post, but only as an unauthenticated user. I'm not sure what Yahoo Groups does; it probably just trusts the From header.
Remember, all mailing lists everywhere do NOT authenticate, they simply trust your From header's email address is correct.
Our problem is, if we go by the trust-their-From-header approach, is to map email addresses to usernames. Could just do a lookup in the metadb users table.
Another idea: a special code in every email that goes out; if you get the code back, you know it's authenticated since it's a reply.

For example, "Don't delete this line: 232jl4jkl3h4iuykj3b4klj3"
Or better, "From: pod_pod_groupname_mareaname_lkjlkjhkjl4hjkh4uiytuy3tuyt4y3gj"
The code would contain info based on user who's receiving it, and where a reply would go. XOR's and hashes galore -- as well as crypto-style security concerns.
Problem: if the email is forwarded on to someone else, they would get the secret code, they could post *seeming* to be the real person. Well, maybe we can trust at this level: remembe,r we'd still be checking their reported "From:" address so unintentional confusion would never result.

spend more time seeing how Quicktopic does it -- their integration is very clean and well-thought out.
ANOTHER APPROACH is to use the In-Reply-To (maybe References too?) header to link together threads, which solves the authentication problem somewhat for replies at least. Gmail seems to use this extensively. it often works well, but I've seen mistakes. They also have bug submission pages which seem to imply they have to look at lots and lots of In-Reply-To headers and hack around the incompatibilities out there. a somewhat pessimistic (though now old) assessment of In-Reply-To is here: http://www.jwz.org/doc/threading.html

Editable vs revisable docuemts.... that is, make two modes of documents to be handled by the system...

editable - changes go to the original document. Edit in-place. Wiki-style. No discussion-viewer comments -- people will have to learn to put comments in-line, wiki-style. Maybe allow preface comments?...

you can't have inserted comments because htey dont work when the doctext is ever-changing. aside from the problem of deleting the location of where the inserted comment used to be, comments become outdated, their semantic context can suddenly change, etc. You can't automatedly solve this without solving the AI problem. Thus, wiki-style inline textual comments are best: people will see them and edit them out manually. This is how discussion work in wiki world.

revisable - changes create new copies. This is what we have now, with disco-viewer comments and all.

Attach a little link?
use the incredibly general refs architecture. it should be good for *something* dang it.

multitiered priority levels
front page announcements hooked into notices.
maybe integrate ALL announcements with the notice system.
notice system should also be a logging system, so that email summaries should query a notice log instead of the status quo which directly queries the msgs table for recent messages. This will allow updates on events in general.

keeps track of who's online and who's not, and if they appear idle (haven't loaded a new page in a while, for example)
this presence system then could say things like "michael, fred, and linda are online right now" on the homepage.
and provide links to send email, or chat/im (see below), or show telephone numbers, or just all contact info via profile...

patch in the authentication system
morph whatever's in phpopenchat into a more general presence system, or integrate it with a presence system in POD
Note: open-source world seems to be moving to Jabber for chat and presence systems. This may not be too applicable to us (at least not yet) since we have everything server-centralized.

htmlarea seems to be the preferred choice these days. it may need some more time to become more mature. But it definitely looks better than a large number of other thru-the-web wysiwyg html editors i've tried at http://www.bris.ac.uk/is/projects/cms/ttw/ttw.html HtmlArea is http://www.interactivetools.com/products/htmlarea/ .
have to rethink how docrefs work. maybe move to a full xhtml/xml system, instead of the hacky space-[\d\d]-space current system.
maybe comments per paragraph, a la quicktopic. this is possible since you have lots of knowledge from the html <P> and <BR> tags, where paragraphs end and begin.
PROGRESS, kinda (1/3/04): successfully grafted htmlarea into moinmoin after several hours work. http://piece.stanford.edu/cgi-bin/wysimoin/moin.cgi . Still experimental. I think htmlarea is still too buggy for realistic use (moz at least. IE htmlarea seems to be a good bit better)

ms monopolistic tactics make this quite difficult, if not impossible. But tremendously useful, if done
we could just ask users to save-as-html then upload, once html format is implemented. This is what QuickTopic doc review does. www.quicktopic.com
opensource converters: I've seen plone developers talk about implementing a wvWare backend to convert .doc -> .html. There are a number of other basic converters out there... antiword for -> .txt, and of course openoffice in server rpc mode could do conversions too.

It might be worthwhile to create another category of options, after decision rule, for what in election parlance is called "turnout requirement", viz, the percentage of eligible voters who must vote for a result to be valid. Could default to 50% (the usual quorum rule), with additional options for "no minimum", 25%, 75%, and 100%. If you don't want to do this now, you should probably add it to the wishlist.

mysql has a simple search mechanism on FULLTEXT fields
we can always build our own primitive indexer over filesystem files.
non-textual docs are a problem: say, word docs
something better: perhaps lucene? simple googling yields few hints on php integration. there's a java <-> php bridge out there but some messageboard comments indicate it's unstable.

DONE: Bulk subscribes -- add a whole bunch of people at once. They all should get confirmation emails or something.