Repository navigation
Use case for Chrome Apps #1
Description
Apologies for what follows as it's a bit of a (long) braindump.
Please feel free to close if I have missed the intention/direction of the project.
TL;DR; Will this project support browser based node implementations?
So myself and a couple of others have kicked of a small project called https://github.com/chromiumify
The idea is to martial all the packages that implement the node api in Chrome Apps as a coherent node runtime.
Currently we have implementations of http, dgram, net, fs and serialport (see https://github.com/chromiumify/project-list#project-list) and I thought it might be useful to share some initial thoughts.
1. Sync API
Having the Sync calls in core is a problem as you can't implement them if you are in a pure JS environment.
e.g. The Chrome App environment has a large set of comparable calls for an implementation of
an 'os' module but this is not feasible as the chrome api is async
See (https://github.com/No9/chrome-os/blob/master/chrome.js#L38) for a sketch of the issue.
My initial thought here is to suggest that the test suite for each module should be broken into sync and async
i.e. ('os-sync-tests') and ('os-tests')
This approach also highlights that all sync calls such as the os.cpu() should also have corresponding async calls specified in the tests.
The async shim could be implemented in userland for node.js but would give alternative runtime implementers options.
2. Porting tests
One of the largest amounts of time spent in the chrome-fs port https://github.com/No9/chrome-fs port is migrating the tests
This is because most of the tests in core rely on the sync api and or process.exit and static fixture folders.
It would be great if these dependencies could be removed in the case of sync and process.exit and removing the need for a fixtures folder
I have ported some of the fs tests to this approach
https://github.com/No9/chrome-fs/tree/master/test/simple
While it's time consuming it's should be possible.
3. Test Coverage
It would be nice if the test suits could output an API coverage document something along the lines of https://github.com/No9/chrome-fs#api-status (?) so it's easy for folks to see what is and isn't available from that implementation.
The node browser projects (chromiumify and browserify) are more loosely coupled allowing core APIs to be swapped out according to needs so this would be great to have for end users.
4. Approach
Are there any ideas for the implementation of the test suite/JSAPI specification?
My hunch was that each module would mirror the abstract-leveldown approach https://github.com/Level/abstract-leveldown but that is very presumptuous as there are probably other ways to go about this too.
Anyway hope some of this is useful.
Activity
trevnorris commentedon Jun 26, 2015
@No9 Thanks much for writing. These types of use cases are exactly what we need in order to create the most practical solution. Allow me to go through and address some of the points:
That hasn't been one of the constraints for the WG, but is something we can take into consideration. At the minimum we can continue to work together and get feedback as the spec is created. Though also note that the existing node API will never be going away. This will sit underneath.
This can definitely be done. At the minimum we can make sure that all sync and async tests do not live in the same file. We could probably even divide them into their own folders.
Does this suggest you think all APIs should always have an async counterpart?
Interesting point. So all async tests will also need to acquire all needed resources asynchronously. This may be difficult to do, but not saying it's off the table.
Will take this into consideration.
Figured we'd just use the standard test suite already included, but that's not set in stone. There may actually be a preferable alternative since vendors will want to run their tests against this.
As far as the JS API. I've been planning this for a year now and have a good idea what it should look like. It comes from researching many different possible implementations and finding the one that worked best for this scenario.
mikeal commentedon Jun 26, 2015
Is this the "libuv.js" that you've mentioned before?
trevnorris commentedon Jun 26, 2015
@mikeal I believe Bert was the first to coin that term when I was explaining the concept a while back, and I jokingly went with it. While it's convenient to say, the strict (or even closely resembling) 1-to-1 correspondence of libuv calls to JS isn't practical. This is definitely be low-level, but not to that extent.
mikeal commentedon Jun 26, 2015
@trevnorris thanks :)
No9 commentedon Jun 27, 2015
@trevnorris thanks for the considered response and I am delighted that you can see potential in the scenario.
Yes I think this will resolve the specific issue I outlined and also provide greater flexibility for other implementations
No9 commentedon Jul 28, 2015
@trevnorris I see https://github.com/nodejs/api/blob/master/js/general_patterns.md has landed.
Thanks very much !!
I also see that Sync calls are still "under discussion" https://github.com/nodejs/api/blob/master/js/general_patterns.md#synchronous-calls
Do I need to transcribe the points against an implicit call made here to somewhere else?
trevnorris commentedon Jul 29, 2015
@No9 Opening a new issue directly addressing sync calls would be best. This thread covers a large number of topics. Thanks!