json description files location

[reno-]

Initially, we thought about a "module" folder, where we could put all our modules in a what-you-want organisation. All modules where json file is found is add as a tag to this module/node, and all modules are known as existant. In SPAN, maybe we won't use this feature (if we just want to work with an existing namespace), so imho it is a project-related function.

If we want to explore some folders to look around json namespace description files, we just have to declare this path. The best place seems to be in the project file, but which key will be better, path or files? We could put media inside this new key…

[reno-]

How do we name this key?

I think "files" is the right name.

How to organize this database?

We should add a key for each file, with it's "filename-extracted-from-its-path" as key and some informations embed in a sub-dict (name - filepath - type - tag etc…) - The key could be a "file-ID" like a stupid index (0 1 2 3 etc…), or the filepath itself, but we want to change sometimes the filepath ("consolidate-to-a-folder option") and it's not very elegant to change the key of the dict.

What do you think about?

[reno-]

About "modules" folder, we could do it with an addon as for media files and use the span.files.maxpat to process the scan of a path.

project-file.json

files key

media sub-key events sub-key “namespace" sub-key

[reno-]

So the scan modules folder should be out of span, it should be in span.files.maxpat utility

[tmays]

If I understand correctly, you want "modules" and other folders to be specific file paths defined for a project, and not a standard part of span. In this case, I think we need to develop the "project type" functions to be able to contain all of this information. I'm not sure that we need to put in a key for every file, but could just have a paths key, and define the folders as we did in tapemovie. There would be a "tapemovie" project type template which would contain inside its "path" key other keys for each tapemovie folder (models, movies, pictures, samples, soundfiles). Another "type" of span project could contain other path names. So I'm not sure why we need a "files" key instead of a "paths" key.

[tmays]

... or maybe that's exactly what you mean, and I would just vote to call the "files" key "paths". Unless you could convince me otherwise...

[reno-]

What I mean is stop storing folder's paths, and storing file's paths otherwise, with a tag to replace the folder location. I guess it is more flexible and it's more coherent with the database approach we have. The nice think with that is that you could have some shared files, like events, media, json etc… and use them with more than one project file on your system. And when you want to export a project, you use the "consolidate/save-to-a-folder" add-on/function. It will copy all files which are referenced in the files dict and put them in a folder, with a copy of your project and all the file's filepaths updated to the new folder. I hope to be as clear as possible ;-) So to summarize (because I change my mind since my last comments on this thread : "files" : { "/hard-drive/folders/afile.json" : { "type" : "JSON", "tags" : "namespace" } }

[tmays]

I still don't follow you. I don't see why it's better to point to a file than to a folder, or why pointing to a file makes it easier to share folders across projects. Each "type" of project (i.e. tapemovie, tolalusulo, etc) defines its own needs where folders are concerned. tapemovie will say it needs events, soundfiles, etc. The project editor can show these "fields" (keys) and allow one to edit them. Maybe there are "project elements" with tags. An element might be "soundfiles" and it may have the tag "path". Then we could parse all elements with the "path" tag and give the use the possibility to change the path, or add another. There could even be a list of paths so that tapemovie could look in several folders to find its soundfiles...

If ever a path defined in the project contains a .json, that could automatically be used to define how that path should be treated, or how it is to be added to the namespace, or whatever.

[reno-]

What I doesn't like with folders, is that everybody in a project have to had the same structure. With my suggestion, it's really free. Something else I doesn't like too much is that when you want to add a file somewhere, or a data file for a module, or something really specific, you have to create a folder and need it to run this patch (like config/data/somethnig)… or do a relative path ro an existing path (like config)… With my suggestion, you just have to add a tag to the file, and the module could easily access to the database and look for this tag. => no need to change folder structure. So see you tomorrow to discuss it !!

[reno-]

Ok, so after intensive discussion, we decided to use a "paths" key with "type" : fold/file So I add a todo to adapt curent span.files module from files to paths