Ideator, project idea planning web-app at neologue.co.uk
this is work-in-progress!
- 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
- 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.
back to Ideator, the web app itself
back to collaborative apps page