While I agree with all this, we don't need a full design spec to start coding. I think the next step is for someone to put together a rough prototype to start with, rather than get bogged down in the details of something that has been talked about for years, but never implemented :-)
Then it can be implemented bit by bit as people have time and interest. So the first question to ask before starting it: which language? Is Tcl workable for people? .hc On 02/05/2013 10:36 AM, Charles Z Henry wrote: > I think that it's a great idea--but the devil's in the details. I think > you need to have a good guiding vision to help you make the decisions about > the implementation--a top-down design > > On the client side, you have to have information about what packages are > installed, where they're installed, what flavor of pd they are installed > for, version information, more? > Dependencies: within Pd, you could be distributing patches that require > some externals--I think it's best for a Pd package system to only reference > dependencies that include other abstractions or externals, not system > libraries. > Maintenance: a system like this needs to be *easy* to maintain---only a > few binary targets can be supported. The rest will need to compile from > source. > > I would start out like this.... make a list and argue point-by-point until > you have a clear plan. > Not that I'm much one to *complete* my projects... but I have a lot of > insight on failing :) > > > On Mon, Feb 4, 2013 at 3:10 AM, colet.patrice <colet.patr...@free.fr> wrote: > >> Hello, that's a quite interesting subject I've been thinking about for pdx >> since a time, thank you for the contribution... like you said it might be >> complicated to resolve all dependences required by an external, so I think >> that adding other dependences like php sql or json would make it even more >> complicated... Why not just using the native client interpreted langage, >> TCL-TK? With the help of a command line like wget included with the tcl >> script and a bunch of pkg files that should be enough, wouldn't it? >> >> >> >> >> >> >> >> -------- Message d'origine -------- >> De : f...@rendera.com.br >> Date : 03/02/2013 20:22 (GMT+00:00) >> A : pd-list@iem.at >> Objet : [PD] Plugin auto install feature to Pure data >> >> >> Hi list >> >> I would like to write before but unfortunately I couldn't. Some weeks ago >> people started to talk about the development of some auto install >> mechanism to Pure Data, like the apt-get. It is an amazing idea. I >> researched and developed some thing like it to my master degree and I >> would like to contrib with my 3 cents. >> >> I studied the plugin structure of Netbeans, Eclipse, Fire Fox, deb and rpm >> and my contribution is about it. Sorry if I am a little bit prolix. >> >> The first thing is to create a plugin package. A a single file to group a >> lot of files. It can be a zip package, tar, gzip or anything that already >> has some C open source API to pack / unpack. This way we can upload / >> download a single file and extract it localy. I will call it the package. >> >> Inside the package is necessary to have a package descriptor. It can be a >> XML file, CSV, txt, JSON or any kind of structured file to describe the >> content of the package. This file should have the information about the >> plugin like the author, version, website, license, OS, dependencies, >> compatibility with PD "flavors" (vanilla, extended, Lork ....), >> pre-installation script, post-installation script, uninstall script, key >> words, ... >> >> Pre and post installation script are used to create SQL tables, files or >> other things. Maybe it is not useful in PD. Uninstall script should clean >> the mess if you want to remove a plugin. Dependencies is a complex problem >> because it should care about libraries and circular dependencies. Maybe it >> is the hardest problem to solve. >> >> These two things will define the PD plugin: The package file and the >> plugin descriptor inside the package. The package structure should be >> defined as a standard. So we should agree, for example, about the name of >> the descriptor, the folder where the plugin will be and the name of the >> package file. Probably a package file can be the name of the >> external.version.something.pd_pkg. >> >> In PD we should have a list of installed plugins. It can be a directory >> with all the plugin descriptors. The user might be able to install new >> plugins manually. It means a local file in my machine that I choose. PD >> will open the package, copy the content to the correct folders and copy >> the descriptor the the correct folder. The uninstall option will do the >> oposite, delete the plugin descriptor and delete the plugin files. >> >> To update from the web, a plugin repository need to be defined. The client >> should have a list of repositories address. (It is good because different >> flavors can have their own plugin repositories and the users can choose >> which one they want to use.) >> >> The plugin server can be implemented with a HTTP server. It will publish >> the list of available plugins on the server. This list can be the list of >> package descriptors in a tar / zip file. Locally, PD will keep these >> lists, one for each server, and it will be used to look for new plugins. >> Add a new server means add the server to the repositories list and >> download the plugin list of the new server. >> >> Since PD has a list of local installed plugins, if you want to check for >> updates PD compares the servers plugin lists with your local list. Easy >> task. Different versions should can be shown and the user would be able to >> choose what to update. These descriptors can be useful also to search for >> plugins by author, version, key words, versions, ... >> >> Update a plugin means to create a list of update, download the packages to >> a temp directory and install them locally. >> >> Just to step foward, the server can have a web interface with some PHP >> programming, for instance, that automatically update a package, extract >> the descriptor, put it in the correct folder and put the plugins in the >> correct folder. Just to be easier to maintenance. >> >> Another tool can help developers to pack. Since I did a new plugin I can >> select the folder, fill a form with the meta-data and the tool will create >> the package automatically. >> >> That's it. Sorry if I wrote too much. >> >> cheers >> >> f schiavoni >> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list