Steffen wrote:
On 05/02/2007, at 15.10, IOhannes m zmoelnig wrote:
help with database-design and -maintenance might be appreciated.
I guess a list of object and there relation can be fetched by parsing the code in CVS. The metadata could provide some description but not per object except for the cases where an external only have one object (or
this i don't understand.
likewise), hence the description of the object will need human interaction (after the parsing code has been written). But i might be all wrong.
I've got a few questions:
- Where (or why) did the project stall?
because the iem changed it's database infrastructure.
- Was it made manually or fetched from the code in CVS?
it was done all manually. in the beginning, one single person maintained the entire database. in the end everybody was given (password protected) access, so they could add their objects.
- How does the term Library in this context relate to the terms External
and Abstraction?
these terms in the pddb are historical and therefore not necessarily appropriate. back then, there were only libraries of externals (afair).
apart from that: personally i am not convinced that the database should be created on the fly from CVS for various reasons:
usually hate to documentate their stuff; so a host of volunteers is needed to do the documentation; they don't necessarily need to interfere with the source-code for this task)
so i think that the database ought to be manually maintained. the existing pddb and the metadata in CVS would be used to initially populate the database.
ideas: everybody can add their objects to the pddb. and eventually delete them. people not "owning" an object should not be able to delete it.
there should be a mechanism to reserve object-names, prior to implementation. if the object is not implemented within a certain time, the reservation expires.
a mechanism to reserve (and document) entire "namespaces" (not necessarily directory-based namespaces!)
...
mfg.asdr IOhannes