[development] relationships API vs i18n

[Derek Wright]

On Nov 9, 2006, at 11:26 PM, Dries Buytaert wrote:

> Having simple, specialized tables (like the one above) is anything  
> but a bad thing, IMO.

so, everyone who wants to use relationships has to fend for  
themselves?  provide their own DB tables, their own APIs, etc, etc?  :(

things i want to use relationships for:

project world:
1) issue <-> issue (duplicate, depends on, etc)
2) issue <-> user (currently hard-coded as 3 things: "assigned",  
"participated", "created", but this is inflexible and there's lots of  
room for improvement).
3) issue <-> cvs commit (currently only 1 way... the commit points to  
the issue, not the other way)
4) project <-> project (related projects, dependencies, sub-projects,  
etc)
5) project <-> user (e.g. email notifications of new releases, but  
lots of potential)

other stuff:
4) user <-> nid (that's all the signup.module should be)
...

i could go on and on...

-1 to me having to implement separate DB tables and APIs for each of  
these things.  that's going to kill progress on any of this (in terms  
of the time it'll take me to do it), increase code bloat, and  
encourage incompatible APIs that are harder for other developers to  
grok, work with, extend, etc.

+1 to giving the relationship itself an id that you can associate  
metadata with (that's what signup.module would be doing).  in fact,  
jeff eaton's proposal to the list seems fairly complete and straight  
forward.

that's how i see it, at least. ;)

thanks,
-derek