Manage modules

vvvv beta general
1

vvvviki: module repository database

Some ideas have been swirling on the shoutbox (and internally since years) about making a centralised repository for modules and patches.
Let me start a spec list and please do give your comments everyone.

  • centralized “submit” webpage where everyone can add a module
  • web-form with (at least) the following fields:
    ** filename (text/short, *.v4p or *.zip or anything)
    ** URL (text/short)
    ** Author (text/short)
    ** short description (text/short)
    ** type (module/patch-demo/patch-tutorial/patch-project/asset/shader/archive?)
    ** submission date
    ** (O) categories (hmmm. associative list like “commercial”,“VJ”,“Art”,“Kiosk”,“Animation-2D”,“Utility”,“Video”??)
    ** (O) language (en/de/ru/jp etc)
    ** (O) long description (memo/HTML) (optional)
    ** (O) version
    ** (O) License (GPL, Copyleft, Creative commons, .-.–?)
    ** (O) status (freeze/stable/alpha/beta/testing/release candidate/outdated?)
    ** (O) screenshot (image / URL)
    ** (O) dependencies (other row from this table)
    **…what else have we got?
  • files could either be uploaded (?) or just referenced (e.g. from the file gallery, or personal web space etc)

Now, when a user submits an item into this database, the following happens:

  • it appears in a centralized list of modules, called the “Repository”
    ** this list can be sorted according to various of the fields.
  • a wiki page for the item is generated automatically, containing the basic information and open for editing/commenting by everyone

Items in the repository

  • can not be deleted.
  • can be declared “outdated”
  • can be recalled on request to the admin (“i didnt want to publish this! ooops! sorry”)
  • can be added to when the filename of a new submission is the same and the version number is different.
2

example for such a thing: http://typo3.org/extensions/

3

some unorganized topics:

*do we really need so much fields for the beginning? i mean it is maybe annoying to fill them?

*detail question: is it necessary to only allow 255 characters in some fields? what advantage do we have from that?

*your appoach creates new wiki pages. that means kalle has to reorganize his modules? i first thought only links to the wikipages are posted into this db. however then you would be forced to first upload your model and afterwards put it into the db. yeah, that’s not cool.

*BIG TOPIC: what about integration with vvvv? wouldn’t it be cool to be able to install to vvvv from within the wiki? if you click the module you will get the files into your help and modules folder. better the other way round: you have a configuration tool (external program) which lists you all modules available on the wiki. (if connected to the internet ;)) you select from within that tool and also are able to manage the modules with this tool. help files, example patches, modules and media will be placed at default places like vvvv\media\xfiles, shader go here: effects\sanch\ … just select the version you need (beta9?) or maybe this tool is delivered with every version and knows what versions are of interest for this version of vvvv.

*security: only the user who uploaded a module should be able to update with a new version? or not necessary at this time?

*alternative views on these modules would be fine. like the 2 sided nodemenu in vvvv. if it would be possible to copy the look of the menu it would be not very necessary, but nice. (and maybe this collapsed view is really important to get an overview?)

*maybe also uploading modules with all media and stuff works with this external program. so some fields (like vvvv version) don’t have to be filled manually. more specifically you don’t load up single modules/shaders/demo-patches… but you always load up “packages”(?) in which you can organize everything you need. e.g.: to show a specific effect you maybe need media like xfiles and textures, help files, demo patches and 2 modules.

*if we have those packages, and an external program, this program could manage to upload the package and if there is more than one module in the package, it just links this package several times into the db. it will automatically fill fields which can be read outof the filename of the modules: “ModuleName (Category Versions).v4p”.

*maybe the modules db really has modules specific fields (Category, Version…), but links to packages. then there is a shader db with shader specific fields (Pixel/VertexShaderversions…) and it mabe also links to the same package. So on the wiki everything is very readable and sorted well. modules can be sorted by Name, Category or Author. (maybe also vvvv version and modification date). Shadrs can be sorted by Pixelshaderverion…

this post went strongly in another direction, but we maybe we should discuss this bigger approach before we start? after starting already anyway…

sebastian

4

good points.

do we really need so much fields for the beginning? Perhaps not. But it wont be less annoying later. You dont need to fill in all of these. (O) is for optional.

s it necessary to only allow 255 characters silly mysql routine. no, not necessary, just an indicatgor for a short field vs. a longer (memo/blob) field,

appoach creates new wiki pages it only creates links to non-existing wiki pages. To create the actual page, you either follow the link or you rename your old module page. Again, it’s just an option, it’s part of the wiki way to have plenty of missing links, too.

what about integration with vvvv reasonable. could be an external app, but why not integrated? __
Or rather should work (on the uploading end) just like uploading a screenshot. only the text edit form you see is a little larger.I don’t know enough about the filestructures to discuss the download part.

security: only the user who uploaded a module should be able to update with a new versio updates don’t overwrite, they just append (or rather, prepend) to the list, and yes, we’d also need to log the uploader name maybe, and allow only registered users (?)

maybe the modules db really has modules specific fields (Category, Version…), but links to packages i added a field “dependencies” to the specs above. This could do it, no? Basically, all asset files or needed modules are linked to the root patch this way. Uh, but it’s shit complicated to do manually. This one does call for the automated uploader.

packages(?) sure, we’ve thought these would be nice before. But it’s a huge issue, no?

post went strongly in another direction well, no. just deeper.

5

packages:

actually a time ago (i think even before the post screenshot to wiki feature) i already did some steps into this direction. it already is able to stuff a package with files, extract them into the right folders, display them nicely and upload them to wiki (attach to a site).
it also can delete files from your local disk (for uninstalling packages), however if some files are included in different packages, yeah, this won’t work the right way yet. therefore some refernce counting file would be needed…
it is built on an opensource zip package library but uses another extension to show the purpose more obvious and to show up with a dark grey icon in the explorer.
sure it would be necessary to look at this app again and make it able to organize many different packages on the local disk (…) however it would be worth another look.

sebastian

6

fleg writes:

modules (vvvv)
could be praktisch. shows a list of installed modules, ability to change the module-path, maybe even the possibility to “browse” , download & install (with a writer) modules available here on this site?

7

just want to share/summarize some thoughts. there is that discussion about how vvvv modules should be organised in the tiki.

i just thought maybe its important to rethink the whole category system at all, not only in the tiki but in vvvv itself. (seems like you developers are on the way to melt those two things together anyway.)

ok, why not drop the category system at all and use tags instead ? we can keep the old category name just as one possible tag, for example the first tag in the list stands for the old category and the following define new ones… this way the traditional nodelist with middle mousebutton can still be generated. but: as a user im looking for a certain functionality and do not think about categories. now if you search for a certain functionality you can enter the tags and narrow down the list by specifiyng more and more tags. i think a more associative approach could have some real advantages. (but maybe also some disadavantages? modules that get lost by wrong or strange tagging?)

i alway felt it difficult to categorise certain modules in a fix defined category. even the built in nodes are sometimes not really clear categorised. especialy the nodes in spread and value do intersect. there are no categories as spread string or spread color… actually many other nodes than in spreads, have possibities that are important for spreading…

for example i (spreads) could have the tags: spreads, value, integer, spreadgenerator
or pipet (ex9.texture) texture, color, image analysis, tracking.

do you know http://del.icio.us ?
its a bookmark managing and sharing system that works quite well for me. maybe something like this is possible for nodes/modules?

8

ja,
we also thought about this.
and as far as i can remember most of us (or even all) were convinced by this idea. i really think we should do that.

only question then is:
how much work is it?

  • built taglists for all nodes (maybe that could be done together in the wiki)
  • implement a search for node function
    suggestion: Ctrl-S creates a node which opens in window mode showing a search field, same like inspector. show all nodes (optional with their short help text?)
  • implement drag-drop of nodes in the search window onto the patch
  • rebuild difff.xml if the namings of the nodes have changed

questions:
if their are many tags associated with a node: should they appear in their name (should they be shown in the dropdown list when creating nodes by just typing?,
should they appear in the .v4p?)

maybe not.
so if not, then we should rename all nodes?
and give them shorter names?
more cryptic names??

hm.

not really clear.

9

“maybe not.”

yeah better not include the tags in the filename, that leads to problems… and the taglist should be open, means that anyone can add tags he like.

“so if not, then we should rename all nodes?”

mh now i see the problem. the categories are included in the filename. when removing the category, all the old patches wont working anymore, despite of the work of renaming all nodes and modules…
and keeping the categories in the name and add additional tags are no really consequent…

"and give them shorter names?
more cryptic names?? "

no shorter names, the names are good and easy to remember like they are, everybody knows stallone and de niro…, the question is, what happens with the category extension in the filename. dont really have a good idea right now.

10

It is probably being discussed elsewhere already, but I’d like to get back to an older idea once again: The About (Patch) Node (or however it may be called).

This node would be placed into a patch and store in it’s inlets all of the Information about the patch as listed above.
When uploading to the vvvviki, the info would automagically be extracted and stored in a searchable index.
Can’t see no reason why this kind of information couldn’t be present in all of the other nodes as well. Ele’s suggestion with the “Tags” would be the same, then, as the field “Categories” I suggested in the first post.

Basically it’s taking the same information I originally suggested to insert in a web form during upload, and leaves it right within a patch. Which is where it belongs.

Locally, on each “rescan for externals” this information could also be gathered so that we could devise an extended nodesearch function.

This also gives a few useful extra capabilities: The node could store the number of re-saves and changes to the patch, and the “save all” function could create a report of whose nodes I am using in a patch, whose copyrights I infringe, automate dependencies, etc.