[PD-dev] Re: Restructuring of CVS/externals

[IOhannes m zmoelnig]

hi.

Hans-Christoph Steiner wrote:
> 
> I've been thinking about this a lot recently, especially with all of  
> the Pd-extended stuff I have been doing.  Here's what I am currently  
> thinking would be the best approach:
> 
> - new code like moocow gets added in the old-style developer directory.

i don't think that this is the _best_ approach (especially as the 
prominent first item of your list), but i agree that it might be the 
most practical.

> 
> - new libraries get defined, like math, net, buffer, mapping, io, etc.
> 
> - lead maintainers get chosen for each library (it could be more than  
> one person)

sounds ok, though - just for the archives - these libraries should be 
structured themselves into sub-libraries (via subdirs), which could be 
maintained by other people than the parent lib.

as for designing the categories i think it would be best to stick to 
existing layouts; probably the one from java (and not the one from perl)

> 
> - the maintainers then design the library, including which objects  
> should be included, make a naming scheme, arguments, messages, etc.
> For example, for a math lib, I think that all conversion objects should  
> have a "2" in the name (cart2pol, f2m, etc. instead of carttopol, ftom,  

(while this is just to illustrate the idea, i wonder why you think this 
(i mean "2" vs "to") is such a good idea....but nevermind

> - then all additions, etc. go thru these maintainers.   What level of  
> control is up to the maintainer.  For me, its very important that a  
> library have a very coherent set of standards.  Other maintainers might  
> have different ideas (though I would encourage them to try to make  
> things as consistent as possible).

i think the main task of the maintainer should be maintainance and not 
development. as a first step it will be mere collecting/revisioning of 
existing objects, then adapting them to a "layout" and finally to write 
the missing parts. (which might be fairly obvious)

> - old developer libraries will be kept for backwards compatibility

i don't think that the stdlib-project's goal should be to totally 
eliminate people's libraries - it should not even cover everything that 
is now in the externals/-folder
i see it as a way to have access to objects for "everyday" usage - not 
for highly sepcialized things.

>> are a plenty of externals that would simultaneously belong to two
>> catagories, like pix_pix2sig~ (not an individual external) which is  both

btw, i don't think that Gem should be part of the stdlib project.
and even if it would, than i would like to have every "real" Gem object 
in "graphics:Gem"

while having things like [pix_video] and [pdp_qt] in the same package 
(as in: sub-package of the stdlib) "graphics:pixel:input" makes some 
functional sense, it will only confuse people into trying to connect 
[pix_video] to [pdp_xv].

of course, this does not mean that both things don't belong into the 
same "category" (from a help-browser point of view), so they should be 
tagged with metadata appropriately.

>>
>> Symlinks possible from an external in one CVS directory?

on w32?

you could have symlinks in the cvsroot (this is: server side of cvs), 
but in the sandbox (client side of the cvs) they will appear separate.
(but if you checkin the changes of one symlink, the other one will 
magically get the changes on next update)




anyhow, i (think i) agree with hans that there is some need for a stdlib 
for pd and that this is _not_ the same as the (also necessary) pddp 
(even though it superficially seems to be so, as they share some keywords)


mfg.asd.r
IOhannes