On Wed, Feb 25, 2009 at 7:33 AM, Hans-Christoph Steiner hans@eds.org wrote:
On Feb 25, 2009, at 5:07 AM, cyrille henry wrote:
João Pais a écrit :
when pd-extended or the cvs will be ordered to have directory like : /math /audio/math /audio/effect /save /matrix
but i would prefer to organise this properly (i.e. not by developer but by functionality)
for now, using flatspace is the only way i know to include code in pd-extended, i'll digg more when i'll get time.
is something like this possible: each developer drops his stuff in svn in the current structure, but when compiled all externals are divided into categories (e.g. like the above named)? each developer has his own corner to drop stuff, but he has to check to which category each object belongs to, and they get distributed at compiling time. and, unchecked objects don't get compiled. is this feasible/logic? it sounds logic to me, as f.e. my abstractions cover a bit of everything: GUI, midi, audio, ... Also, the amount of categories should be discussed, and probably on the main list. I think that MP's original list isn't enough, and new categories should be included (especially considering the amount and diversity of objects in pd-ext). audio filters, generators, effects, ... I can look at the pd-ext-list I've made and give a concrete suggestion in the next days, if you want. this discussion will be a bit chaotic, but it should go to the main list/pdpedia.
yes,i think such proposition can be constructive.
Honestly, I think the libraries should not be automatically formed. They should be owned by someone and designed as a whole, not pieced together from random bits. This is how libraries are usually written in Perl, Python, etc. etc. This would ensure that the objectclasses in a library have matching interfaces, and work well together.
My suggestion is certainly aimed towards that goal, but tackled with an iterative approach.
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 : ) ) * 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.
One of the benefits of this is it will become much clearer what that common interface should be once many objects of the same type are collected together. And I think it will be much more likely for maintainers to step forward once the libraries are loosely assembled, since the potential will be so much clearer.
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.
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.
Does that make sense? Best Luke
.hc
Mistrust authority - promote decentralization. - the hacker ethic
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev