pcplantdb

[John Schinnerer <john@eco-living.net>]

Aloha,

> > User interface will provide ability for user to creat an account.
> >   Account creation requires a user name consisting of min. X max. Y 
> > alphanumeric characters from sets [A-Z][a-z][0-9]
> >   Account creation requires a user password consisting of min. X max. 
> > Y alphanumeric character from sets [A-Z][a-z][0-9][!@#$%&*_-=+]
> >   Account creation is accomplished using a GUI form with a field for 
> > user name entry, a field for password entry, a field for password 
> > verification and a form submission button.
> >   Submission step one includes validating the user name, validating 
> > the password, validating that password matches password confiramtion 
> > field.
> >   Submission step two passes the valid user name and password to the 
> > user account creation function/method/routine and verifies no errors 
> > were raised in creation.
>
>
> All good stuff. Might want to add some other user info, email address, 
> web page.

Yeah yeah, that's just a quick example of format.  Lots more to deal with.

> The question here is that designing a DB which has user input may have 
> very different structure to a straightforward readonly DB with no input.

Well, all DBs have input from somewhere or they'd be empty...

> When you bring users into the picture a number of issues occur
> 1) Can users just add data or do they have full edit facilities
> 2) If edit then we need some form of history management
>     so that bad edits can be undone.
> 3) Is user input just a comment at the end or is it interweaved with the 
>  different sections in the data. Chad's alluded to something along this 
> line:
>
> > The concept of being able to attach a comment to every/any 'object' is
> > a concept I am quite into.  Defining object granularity as a sentence
> > is a little smaller than I had in mind.  I was thinking more along the
> > lines of a comment being the smallest object, but this could be
> > multiple paragraphs.  

All above was one of my reasons for pushing for ODB instead of RDB.

> My take is that it would be posible to attach a comment to "info on 
> edible uses", or attach a comment to "info on medicinal uses".

That makes sense search/research wise to me.

> Permisions keep simple: Read / Add / Edit / Admin (can do anything)

Yeah, just needs to be spec'd in writing.

> A lot of what JohnS has written seems like it should go in a formal spec 
> document.

Fine with me if it's used as a starting point...

> We need to create a formal spec document. This could be:
> a) wiki page
> b) cvs file
> c) something in the issue tracker?

Aye, there's the rub...how exactly?

It needs to be something we can collaboratively edit, ideally residing 
in one location and safe from conflicting updates.

CVS might suit best - check in/out takes care of conflicting updates and 
gives a central repository.

Issue tracker I don't think would work too well, if at all.

Wiki page too limited by need to do some kind of formatting/markup.
That's what word processors are for.

How about an RTF format document in a CVS somewhere?

John S.

--

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net