Resource Management

[grandchild]

Resource Management

[azeem]

Image resources are currently loaded with 'new Image()' object and setting the 'src'. This has multiple nice consequences

1. Images can be loaded from any web resource asynchronously with URLs. Have to check out cross-origin policies on this, im guessing you can load files from anywhere, the same way we can embed img tags from any location.
2. We can use base64 encoded data. instead of a url we can just provide the raw data directly in the css "mimetpye+base64" format. This means the image binary can be included in the preset json itself. This i think allows the preset-internal resources that you mention

As for global resources im including a Resources object (https://github.com/azeem/webvs/blob/1.1dev/src/Resources.js) that contains common resources. If the present json mentions a key in the Resources object instead of a URL or Base64 data then its loaded from the Resources object (check texer example https://github.com/azeem/webvs/blob/1.1dev/examples/PilloFight.html).

As for packs, i agree with you, it makes limited sense. But if anyone wants to package Webvs the library with preset packs then registering pack level resources is as simple as adding more data into Webvs.Resources object. This can even be done at runtime without touching the library code.

[QOAL]

How about a media object in the root of the preset.
Taking the form of "media": {"fileName":"data/url"}
It would contain any embedded media and urls pointing to either standalone media or packs of media.
I think media packs would compliment WebVS packs (if we get to such a thing), its sympathetic to AVS installers.
They (media packs) would probably better suited to having base64 encoded entries only, to reduce http requests.
localstorage could be optionally used to cache fetched media.

The media could then be added to Webvs.Resources as azeem wrote about above.

The only downside of allowing external stuff is

• This is the internet, things go down and disappear
• Cross domain security policies (Not a problem with CORS)

So when converting presets, I guess it would be best to convert them a pack at a time, and generate a media pack for the pack (ignoring Tug's texer resource files)

Also I converted all (85) of Tug's texer resources to base64/pngs: https://github.com/QOAL/qios-webvseditor/blob/master/avsres.js

[azeem]

I like the "media": {"fileName":"data/url"} idea. if a file is being used multiple times (like texer image for example) then this can avoid repetition.

I agree with you on external files. Its not much of an advantage when you can just robustly embed the image as base64 data itself. Its just a nice addon that comes for free since loading of images work the same in either case. Going further, if there are other non-image types of binary resources that we might want to use then embedding seems to be the cleaner way to go.

[azeem]

I have added a ResourceManager system (https://github.com/azeem/webvs/blob/1.2dev/src/ResourceManager.js) that (hopefully) addresses some of the issues discussed in this thread and here: #13

So here is how it works right now.

• ResourceManager maintains a map between filenames and URI (could be URL or data URI)
• In the JSON, for individual effects, the resources will be specified only by filenames
• When a resource is required by an effect, it asks the ResourceManager, which then looks up the URI and loads the resource.

Now, there are different ways to setup this filename to URI map in the resource manager

1. From the preset JSON. a resources field in the root eg:

   "resources": { 
     "uris": {
       "abc.png": "http://example.com/abc.png",
       "def.bmp": "data:image/png;base64;..."
     }
   }
   

2. Programatically. by calling registerUri on ResourceManager. UIs can use this. When preset JSON's are generated later with a getPreset call, the resources field is automatically added

3. Builtin resource packs. This is just a bunch of default files that the Webvs library user is expected to put at a fixed location.

4. And may be later from External resource packs.