Ideator, project idea planning web-app at neologue.co.uk

To-Do notes!

• Need to add a load more controls such as moving items about, deleting items. Don't know what to do about deleting lists.
• Need to have it escape < and > characters because we don't want any HTML tags insertable by the user. Not even italics or crap, it's just not worth the hassle. BBCode might be ok, there are PHP modules for processing that (not sure if they are on here though).
• Limit items to maybe 1K or 2K bytes. That's equivalent to half or a full terminal window full of text, which should be plenty for one item. If you have to write more, you should be breaking it up into multiple items for intelligibility, or splitting it into separate concepts etc. Main reason for making this limit is to prevent users flooding the server with too much data, it does have to be stored somewhere.
• A separate user login system is about 90% done now, and vaguely works, but Ideator has to be adapted somewhat to make use of it. Most obvious change will be the use of per-user outline files for storing your data, instead of cookies, making the data properly persistent (although it may still get lost by corruption due to significant code changes). Storing data in files will not allow editing to be collaborative (without either difficult safeguards or the risk of corruption), but it will enable each user to show others their outline data.
• Actually, it could be possible to make a variant of this that is collaborative: shared outlines come with a separate file describing if it is locked, and by whom. Special program would have to be made to deal with trying to lock the thing, because file locking via flock doesn't work over NFS, and PHP doesn't natively support the method using fcntl- so the latter would have to be done in C or Perl or something, and would then have to communicate whether or not it got the lock, back to the calling PHP script. Unfortunately it's not feasible to allow finer granularity than locking the whole outline at once this way.
• Storing outlines in big files would be largely like doing it in cookies, but it would probably be desirable to use the file() function to read it all into an array, which would require using newline as a list delimiter, rather than _; . In turn, that would mean that newlines in the items text should either be escaped, or turned to whitespace. The latter is probably desirable, but I dunno.
• In this model, getting lists of users with access to your group outline, or outlines your user account has access to, is probably difficult. That might be best done with SQL regardless of anything else.
• OR I may skip that version and go straight onto...
• Final ideal version, will have user logins and collaboration groups, and one file per-group, with the ability for users to create groups and invite others to join either to edit the outline or just view it (if the outline should be mostly private).
  Not sure exactly how concurrency issues would be handled there, maybe it'd all be done via SQL database (probably necessary?). I think the best way would be for editing operations to take 2 steps, the first of which starts the editing process (giving a form to poke at, etc), and simultaneously locks the relevant parts to prevent others being able to edit them at the same time. There should probably be a note saying that if someone holds a lock for 12h or so, then it will be automatically released. Ok, 1h is more like it. Sessions only last 40 mins if the user is idle, anyway.
• In this model, there'd be a table of outline groups, each of which has a listID to describe its root list. Then there's a table of lists (duh!), each of which is a string similar to the ones used for the cookies and file versions, but just one list. Difference is that the list ID and parent ID and title, would be separate attributes in the table, from the list string data. In this way, individual items aren't database entries, only lists are. This makes it somewhat harder to move an item around inside a list, and harder still to move it to another list. But these things will be done relatively rarely. Displaying a list will be faster, as the database doesn't have to find lots of separate item entries, so browsing the outline should be less resource-intensive.