Hans-Christoph Steiner wrote:
On Jun 21, 2008, at 1:26 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think then there could be a simple distro system like Eclipse has for managing plugins. (Basically, there is a simple format for posting a library to a website. The user then adds the repo URL to the program, which then has a browser for all available installation options and updates).
Recently another metaphor came to my mind - and of course it has to be taken with a grain of salt like all metaphors: Mozilla vs. Firefox/Thunderbird/Sundbird, ...
pd-extended to me very much feels like Mozilla in that it tries to provide as much "apps" as possible crammed into a single-click installable suite. Compare that to Firefox, which is only a very basic browser with functionality stripped down so much, that the first thing everyone does is install some extenstions. Nevertheless Firefox took off in a big way and Mozilla is more or less dead.
I think, this had two reasons. First reason: People who liked the browser in Mozilla didn't care about the mail component at that time. They used Mutt, Outlook, or whatever. (Funnily now that it's a separate app, Thunderbird became popular as well.) The second reason is the extensions and theme system of Firefox which made it very easy to install only the updates, that a user is interested in, without all the bloat of Mozilla.
I don't know if something can be learned from that history, though.
I think it is a good example. Mozilla needed to happen in order to make Firefox, Thunderbird, etc. happen. But it then worked better to split them up. I think Pd-extended is a similar kind of thing. Gathering all known code at the time into one place need to happen to get the community to the next step. Now we are outgrowing that model, so I think it is time to split things up so that externals are as well supported as internals.
Then there is much less need for a 'gatekeeper', who has control over what is included (e.g. like Miller for vanilla, or me, mostly, for Pd- extended). If we make it easy to find, download, and manage externals, then we don't need a big central package. Something like CPAN is a great example, or the Eclipse plugins.
is this a proposal for a "package system"?
well, it would be a step forward just if only all extern will work ./configure && make && make install out-of-the box.
what I see lacking in the external repository is some kind of standard. most externals build with just a makefile, some others use automake, autoconf, others use the flext build system.
another problem is the install location: since the addition of namespaces/declare/import, things are changed. also, the standards are very low (I again advice to read the GNU coding standards book)
also, the install location of docs, it is a flat (bloated) directory (?)
also, externals/packages, lack versioning (I think). do we have the possibility to put metadata?
I'm not proposing a valuable solution, just spotting one problem.
I hardly see a user-friendly, plug-n-play system for extensions right now; tidying up things is required.
What if every external installs into his own prefix in ${ROOT}/usr/lib/pd ? example: /usr/lib/pd/zexy/lib/a2l.pd_linux /usr/lib/pd/zexy/lib/abs~.pd_linux ... /usr/lib/pd/zexy/doc/help-a2l.pd /usr/lib/pd/zexy/doc/help-abs~.pd ... /usr/lib/pd/zexy/package.xml ?metadata?
at this point the /pd/ is superfluous. the Tcl package system works by putting directories directly into /usr/lib, example:
/usr/lib/tktray1.1/ /usr/lib/tktray1.1/pkgIndex.tcl /usr/lib/tktray1.1/libtktray1.1.so
not bad, IMHO.
my 0.02€