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