Restructuring of CVS/externals [was: Re: [PD-dev] moocow's libs]

[Hans-Christoph Steiner]

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.

- 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)

- 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,  
etc.  for messages, use [reset( everywhere instead of also sometimes  
[clear(,

- 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).

- old developer libraries will be kept for backwards compatibility

- meta data would be used for a class browser, a help browser, etc.   
There could be many keywords or categories, and an object could be  
included in many of these categories.


And to address some of Ben's ideas, I think that not having things  
organized into libraries makes it impossible to have a full namespace  
like Java.  Here is the wiki page I started to outline these ideas:

http://puredata.org/dev/PdLibraries

Ben's page is somewhat related, but I think that page is more related  
to PDDP, then we could use it to start mapping out the meta data  
categories that we want to use for the class/help browser.

.hc

On Feb 1, 2006, at 12:28 PM, B. Bogart wrote:

> Hey all,
>
> I think one factor that would make the organization of the externals
> easier is NOT to structure the CVS in that way. What I mean is that  
> there
> are a plenty of externals that would simultaneously belong to two
> catagories, like pix_pix2sig~ (not an individual external) which is  
> both
> audio and video... If we don't have to worry about externals belonging  
> to
> a particular catagory exclusively then that would make the organization
> more accurate, and solve some stalemakes.
>
> Symlinks possible from an external in one CVS directory?
>
> The whole help-patch meta-data searching idea would make finding  
> externals
> very easy, there could even be a commandline version that searches the  
> CVS
> for a file with the keywords "gem, texture signal" and get a list of
> matching externals. Mathieu would even like to see a tree of externals
> that is generated from the keywords.
>
> Anyhow the organization of externals (for the user) need not be the
> representation us (the developers) have.
>
> One directory for each external
> In that directory: one external-help.pd for each external (main  
> reference
> patch) w/ meta-data. plus all the other stuff.
>
>
> heck searching of the CVS could be done on the server too... (not just
> locally on a checked out copy)
>
> Just a template for how to organize stuff in CVS could be handy (at  
> least
> for externals if not libs etc..) but we'll never agree so why bother?  
> ;)
>
> How about contribuing to:
>
> http://puredata.org/Members/bbogart/CatagoriesForExternals/view? 
> searchterm=externals
>
> As a start?
>
> .b..
>
> On Wed, February 1, 2006 11:48 am, Frank Barknecht said:
>> Hallo,
>> cdr hat gesagt: // cdr wrote:
>>
>>>>> externals/${developer}/${package}/ ?
>>>>
>>>> it (imo: unfortunately) seems to be like that
>>>
>>> there are some subdirs like signal/ and control/ now..  which could
>>> have new subdirs like filters, logic, math, filetypes...maybe the
>>> toplevel dirs could be tagged with ALLCAPS categories files for
>>> rearrangement when switching to SVN..
>>
>> That's great! For quite some time now I would like to give away some
>> of my externals to the community by moving them out of
>> externals/footils, namely knob and buzz~. However before I do this, it
>> would be good to agree on some concrete structure for this. Then every
>> developer could decide when to move stuff out of the personalized
>> directory into project-directories.
>>
>> Ciao
>> --
>>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>>
>> _______________________________________________
>> PD-dev mailing list
>> PD-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>>
>
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>

________________________________________________________________________ 
____

  As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously.
                                                   - Benjamin Franklin