[PD] [Spam] RE : Re: RE : Plugin auto install feature to Pure data

[fls at rendera.com.br]

Hi Colet

I don't think so. We can think about several servers (repositories) that
the user can choose. So pd-extended can have an official repository and I
can have mine.

f schiavoni

> Wget and tar could be replaced with TCL http and tar module at client
> side, and for server side I'd use PHP and mySQL, or maybe python instead
> of PHP... One thing I'm wondering is how to share packages between several
> servers, would all http servers need a build farm?
>
> -------- Message d'origine --------
> De : fls at rendera.com.br
> Date : 04/02/2013  17:57  (GMT+00:00)
> A : pd-list at iem.at,"colet.patrice" <colet.patrice at free.fr>
> Objet : Re: RE : [PD] Plugin auto install feature to Pure data
>
> I'm not used with TCL Tk but my guess it that it should be enough. In
> linux wget + tar + shell script can solve it. I don't know how portable is
> a solution like this.
>
> The PHP + SQL was just a suggestion of a tool to update the repository.
> Nothing about PD.
>
> About the dependencies, if the external uses only the ANSI C API, it will
> not be a problem. It is more confuse if it uses some special lib that
> should be installed with the external. As I would not like to install
> automatically a new library in my machine, I think the plugin descriptor
> can has a field called instruction where the author can specify how to
> install the dependencies. And that's it.
>
> cheers
>
> f schiavoni
>
>
>> 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 : fls at rendera.com.br
>> Date : 03/02/2013Â  20:22Â  (GMT+00:00)
>> A : pd-list at 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 at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
>