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...
Envoyé depuis mon appareil mobile Samsung
-------- Message d'origine -------- De : Hans-Christoph Steiner hans@at.or.at Date : 05/02/2013 16:20 (GMT+00:00) A : pd-list@iem.at Objet : [PD] package system for Pd WAS: Plugin auto install feature to Pure data
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.patrice@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 : fls@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
I think really the key is to find someone who is going to start working on this, then help them figure out the issues as they request it. I think its counterproductive if we set up too many conditions of starting if none of us are going to work on it :-) Then they can decide Tcl or something else, client or server first, or whatever else.
Who wants to try the first sketch? We have a package format to start with, its something, but it'll surely need to be changed to support all the ideas: http://puredata.info/docs/developer/LibraryTemplate
.hc
On 02/05/2013 12:48 PM, colet.patrice wrote:
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...
Envoyé depuis mon appareil mobile Samsung
-------- Message d'origine -------- De : Hans-Christoph Steiner hans@at.or.at Date : 05/02/2013 16:20 (GMT+00:00) A : pd-list@iem.at Objet : [PD] package system for Pd WAS: Plugin auto install feature to Pure data
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.patrice@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 : fls@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
sounds right up my alley but i have not a clue about how to write a line of code in tcl , python nor lua. i was trying to convert the big bunch of wafscript to just a simpl makefile for compiling pugl today and by the time i could get to the end of the spaghetti i realized i don't even remember how to write a make file haha. but i'm still chuggin away at it.
On Tue, Feb 5, 2013 at 1:33 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I think really the key is to find someone who is going to start working on this, then help them figure out the issues as they request it. I think its counterproductive if we set up too many conditions of starting if none of us are going to work on it :-) Then they can decide Tcl or something else, client or server first, or whatever else.
Who wants to try the first sketch? We have a package format to start with, its something, but it'll surely need to be changed to support all the ideas: http://puredata.info/docs/developer/LibraryTemplate
.hc
On 02/05/2013 12:48 PM, colet.patrice wrote:
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...
Envoyé depuis mon appareil mobile Samsung
-------- Message d'origine -------- De : Hans-Christoph Steiner hans@at.or.at Date : 05/02/2013 16:20 (GMT+00:00) A : pd-list@iem.at Objet : [PD] package system for Pd WAS: Plugin auto install feature to Pure data
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.patrice@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 : fls@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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Try writing something in a language you are familiar with. Anything working is better than nothing :)
Tcl is a bit odd, but its pretty easy for almost all of what this project would require.
.hc
On 02/05/2013 11:08 PM, Billy Stiltner wrote:
sounds right up my alley but i have not a clue about how to write a line of code in tcl , python nor lua. i was trying to convert the big bunch of wafscript to just a simpl makefile for compiling pugl today and by the time i could get to the end of the spaghetti i realized i don't even remember how to write a make file haha. but i'm still chuggin away at it.
On Tue, Feb 5, 2013 at 1:33 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I think really the key is to find someone who is going to start working on this, then help them figure out the issues as they request it. I think its counterproductive if we set up too many conditions of starting if none of us are going to work on it :-) Then they can decide Tcl or something else, client or server first, or whatever else.
Who wants to try the first sketch? We have a package format to start with, its something, but it'll surely need to be changed to support all the ideas: http://puredata.info/docs/developer/LibraryTemplate
.hc
On 02/05/2013 12:48 PM, colet.patrice wrote:
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...
Envoyé depuis mon appareil mobile Samsung
-------- Message d'origine -------- De : Hans-Christoph Steiner hans@at.or.at Date : 05/02/2013 16:20 (GMT+00:00) A : pd-list@iem.at Objet : [PD] package system for Pd WAS: Plugin auto install feature to Pure data
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.patrice@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 : fls@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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Billy Stiltner -
colet.patrice -
Hans-Christoph Steiner