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