Basically, organization of the libs could not really be any /worse/ than it is now (e.g. I'm constantly checking ggee, hcs, moonlib and zexy to find various OS and filesystem externals I need), so I'm basically proposing the same thing you are, but approached as follows:
- Lazy consensus on a directory structure (I think we were already
making very nice progress on that in the "Proposals for object categories" thread before it went off track : ) )
I can start organising the info in a wiki page later in the day. I guess this is point where we all agreed, we should try to move in the direction of a structured pd-ext?
- Creation of a branch of SVN with the directory structure in place
- Everyone works together to shuffle the many libs into the new structure
- We each claim a domain we'd like to maintain
- And then, finally, the maintainer (with help from consenting
developers where necessary) begin to rewrite the objects in that category to have a consistent interface.
is the consistent interface really necessary? there was already some discussion about the layout for the pddp project (am I right?), maybe elements from there could be taken? or maybe it's enough to provide a general template with guidelines to be followed, in case the developer wants the objects to become part of pd-ext? f.e., I have a consistent approach to the documentation of my abstractions - of course I can use another graphical template, but that might open lots of unecessary discussions: "why these colors", "why this layout", "why so many graphics and not only text", .....
But I think that in general it should be stressed that objects should be stable and properly documented.
And of course this does not need to be a mandate - if a developer would rather keep all his/her stuff together, that's fine. And, there will always be exceptions like rtc-lib or sigpack that shouldn't really be split up.
shouldn't they really? depends on what you're talking about - rtc, vasp, etc. are very cohese libs, that anyway don't go much outside their domains - their developers even made that separation clear, by putting other externals available elsewhere. they could easily go to /control/rtc or /control/array/vasp or etc. But for not so tight lib-packages, is it that bad to separate objects, as long as they're all available on path?
But, on the other side, I'm assuming there are many developers that would be more than happy to move their code into common categories - at the very least including myself, João and Cyrille, and only haven't done so because the structure did not exist. And personally I'd be just as willing to adapt the interfaces of my abstractions to a category-defined standard, but once again, none exists now to adapt to.
I have no problem in structuring my abstractions (I can't code), but my "lib" is probably one of the most simple ones.