Roman Haefeli wrote: > hi marius, hi iohannes > > > 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.
fair enough but what about all those libraries that are not in pd-extended? do they have to stay outside the wiki until they are extendified? > > 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. > i haven't even been at the pd-doc meeting and still have to have my say. anyhow, thanks for the sum-up. fmasdr. IOhannes _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
