[PD] representning classes and selectors in the wiki

[Roman Haefeli]

hi marius, hi iohannes

sorry to chime whitout having participated yet to this discussion at
all, 

On Wed, 2007-09-12 at 17:17 +0200, IOhannes m zmoelnig wrote:
> marius schebella wrote:
> > 
> > how stable is the library structure? if it is stable over several years, 
> > then it could be arbitrary. but some objects jump around. from zexy to 
> > iem (mtx?), from iemlib1 to iemlib (don't know if that is really the 
> > case...) from iemlib to puredata core (gui)... from everywhere to 
> > "flatspace".
> 
> 
> wow:
> zexy had the matrix objects for several years (they first appeared 
> therein in 2001; and they vanished by 2005)
> iemmatrix has the matrix objects for several years too (2005-today)
> 
> iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3) and a 
> collection of abstractions; this has not changed since i know this 
> library (which is quite some time)
> i don't know which object has moved from the sub-package "iemlib1" to 
> the meta-package "iemlib". i thought this would be impossible, given the 
> structure of the iemlib.
> 
> let us not be troubled by repackaging of objects.

but i am. it's not only, that objects (or 'classes') used to move from
one to the other, but they exist at two different places at the same
time, dependent on whether you are using pd-extended (with libdir
format) or pd-vanilla with the original externals. iemlib is a good
example, lets stick with this one. [hp1~] is part of 'iemabs' in
pd-vanilla and part of 'iemlib' in pd-extended. if you want to use
namespaces for instantiating the objects, it doesn't work
crosscompatible on both distros. 

however, this is actually a different story, but probably affects the
way we want to implement the wiki. since there _are_ incompatibilites
between pd-vanilla/original libs and pd-extended, i vehemently propose
to decide which route to follow for the database: the
'pd-vanilla/externals' way or the 'pd-extended' way. let's also face who
is actually addressed with this database. one of its goals is to have
all information about objects available at one place, which is, i think,
fairly essential for people, who are new to pd and want to explore all
facets of pd. i also believe, that most of these people will use
pd-extended, since it is by far the easiest way to get 'just
everything'. taking into account all these points, i strongly believe,
that it would be the best way to reflect the pd-extended topology in the
database, none the less just because people, who compile pd and
externals themselves could live more easily with incostistencies between
their pd installation and the database than less experienced pd users.

to sum it up, i'd vote for:

[url]/[libname]: 		description of a library
[url]/[libname]/[objectname]:   description of the object 

(i am not an wiki expert at all and also don't know, if these proposal
can be represented in mediawiki [or i a wiki in generel])

why making it flat und having to deal with nameconflicts, when the
libdir was introduced in order to just avoid that?

yo, i hope i didn't bring something up, that has been discussed and
defined before already, since i missed the major part of the pd-doc
meeting.

roman

 





		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de