[API] Handler VFS method call consistency

[RickGlimmer]

At the moment _NullModule.read (in src\client\javascript\vfs_null.js) is the only function that does not use the handler that is returned by OSjs.Core.getHandler(). I see that the .write has been changed to use the handler.
Would it not be possible to make a OSjs.VFS.internalCall so that i can process this in my custom handler?

[andersevenrud]

Update for this is coming later today. There are some other changes coming relating to this coming :)

[RickGlimmer]

👍 Great!. I will concentrate on my backend first. :)

[andersevenrud]

Hm. I've been working on the VFS today, and now I'm not sure what you're talking about.

My Handler::onVFSRequest() is triggering on all modules. It's the main wrapper for all VFS calls

OS.js/src/client/javascript/vfs.js

Line 200 in f24f5aa

function request(test, method, args, callback, options) {

[RickGlimmer]

it is the following part. All others ('write','exists' etc) use OSjs.VFS.internalCall and use the loaded handler. This one has its own Ajax part that it uses.

  _NullModule.read = function(item, callback, options) {
    options = options || {};
    options.onprogress = options.onprogress || function() {};
    if ( API.getConfig('Connection.Type') === 'nw' ) {
      OSjs.Core.getHandler().nw.request('fs', {
        'method': 'read',
        'arguments': [
          item.path,
          {raw: true}
        ]
      }, function(err, res) {
        callback(err, res);
      });
      return;
    }
    this.url(item, function(error, url) {
      if ( error ) {
        return callback(error);
      }
      Utils.ajax({
        url: url,
        method: 'GET',
        responseType: 'arraybuffer',
        onprogress: function(ev) {
          if ( ev.lengthComputable ) {
            options.onprogress(ev, ev.loaded / ev.total);
          } else {
            options.onprogress(ev, -1);
          }
        },
        onsuccess: function(response, xhr) {
          if ( !xhr || xhr.status === 404 || xhr.status === 500 ) {
            callback(xhr.statusText || response);
            return;
          }
          callback(false, response);
        },
        onerror: function(error) {
          callback(error);
        }
      });
    });
  };

[RickGlimmer]

I see you moved some files. It is now in internal.js on line 93
internalTransport.read = function(item, callback, options) {

[andersevenrud]

I see you moved some files. It is now in internal.js

I just made some changed to properly name and split some sections. Functionality has not changed :)

it is the following part. All others ('write','exists' etc) use OSjs.VFS.internalCall and use the loaded handler. This one has its own Ajax part that it uses.

That's because I use a XHR request that returns ArrayBuffer. This is best done with the browser API and not channel through the backend.

I can make it possible to customize this as well. Just have to think it out first.

[RickGlimmer]

If the 'write' goes through the handler i think the read should do the same. The handler could return an ArrayBuffer as well.
It will keep everything together which is more convenient. It took me some time to find this exception to the 'rule' and that makes maintaining/porting a bit more difficult. It is also one of the few original files that i needed to change to get my backend working. Ideally all code that uses a different backend should be in the custom handler.

[andersevenrud]

This was added to the branch https://github.com/os-js/OS.js/tree/new-api-uris.

https://github.com/os-js/OS.js/blob/new-api-uris/src/client/javascript/handler.js#L341

You can now hook into them all:

• _callNW() for NW builds
• _callAPI() normal API and VFS calls
• _callXHR() this is the function you want to modify

[andersevenrud]

I might change the name from XHR to GET or something like that instead

[andersevenrud]

Ok. So now the handler has these:

• _callNW() For NW.js builds
• _callAPI() For API and VFS calls
• _callGET() For VFS file reads/downloads
• _callPOST() For VFS [browser] file uploads

That should cover everything :)

[RickGlimmer]

Maybe even split _callAPI into _callAPI and _callVFS. Then everything has its own.

[andersevenrud]

• __callXHR() Setup for all general browser API/VFS calls
• __callGET() Setup for reads/downloads
• __callPOST() Setup for browser file uploads
• _callAPI() Wrapper API calls
• _callVFS() Wrapper VFS calls

[andersevenrud]

Superseeded by #304