Re: [Debian-sf-devel] Future functionality questions...

[Tim Uckun]

> Here's a use case description of the improved foundry system might be used
> and how it might be useful to you.  (I agree that task tracking is something
> I would love to see handled better, too! )

Very interesting. I have been thinking about this for a long time and the 
conclusion I came to was this.
What is REALLY needed are two things. A generic hierarchical object and a 
generic symlink object. The hierarchy stores symlinks. Each object has a 
unique ID (OID or a serial). The symlink is what is stored in the 
hierarchy. Each hierarchy is nothing but a table containing the leaf nodes 
and the symlink. I was thinking about coding up the examples in the "SQL 
for smarties" book by Joe Celko.

My thinking goes like this.

All things have a context. Users, departments, documents, discussions, 
bugs, feature requests etc. All of these are usually expressed as a 
hierarchy. If you could coneniently ask questions about the object like 
(list all parents, list all children, reparent this object etc) then 
everything else falls into place easily. No need to try and warp metaphors. 
Instead of saying "a foundry is like a dept" you simply create a new table 
(hiearchy) and call it a dept. The dept could be sub dept of anything. It 
could contain members (another table = another hierarchy) etc.

I don't know if I am making myself very clear but if you look at SF you 
will see that it contains nothing but hierarchies. It seems to me if we 
attacked that core everything else would fall into place including complex 
ACL types of systems.


:wq
Tim Uckun
US Investigations Services/Due Diligence
 http://www.diligence.com/