GPII Orca settings handler

[javihernandez]

see http://issues.gpii.net/browse/GPII-82

reviewing, testing and commenting will be appreciated ;)

Cheers!

[sgithens]

Hi Javi,

Do you have an example of the updated Solutions JSON and a Preferences JSON for one of the demo users that I can use to try this out?

Cheers,
Steve

[javihernandez]

Hi Steve!

After this last commit, I think we're almost ready to merge this. Anyway, I'm hoping on include some unit tests in a couple of days. You can use this personal branch 1 of the universal repo to test the Orca settings handler. There you'll find the integration of this settings handler as a solution and a user profile (orca1) for testing purposes.

Best regards!
Javi

[yzen]

Please use path.resolve to build paths.

[yzen]

Also, @javihernandez, given that it's somewhat similar to the default settings handlers, could you supply some unit tests along with the pull requests. Thanks.

[yzen]

@javihernandez, is this ready for another round of review? I noticed there are still some tweaks missing based on the IRC conversation (http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2013-06-20) re common utils method and overall asynchrony..

[yzen]

get and set parsers are now part of the framework: fluid.model.escapedGetConfig and fluid.model.escapedSetConfig

[yzen]

Just: var curDate;

[yzen]

@javihernandez your pull request looks good. Could you also add a TODO note around wait and mention that this needs to be converted to an asynchronous as soon as the lifecycle manager can handle asynchronous actions. Also mention a stability risk since if the file never arrives the system deadlocks.

[amb26]

As it stands, this blocking loop is a big stability risk to the system, since it blocks the node event loop possibly indefinitely. If we absolutely must get this in for GPII 0.2 we can accept it, with a huge warning applied to it, but we should move to a properly asynchronous system as soon as possible (requires fixes in universal). Since this code would only be used on a single-user system we could argue that the risk isn't completely serious - but in general we have a lot of work to do in GPII to ensure that all possible sequences of activites, including multiple logon, logoff, and I/O errors always leave the system responsive and in a consistent state.

A simple improvement here might be to impose a maximum waiting time for the file, after which we error out and return control to node - at least we can guarantee then that the system will not block indefinitely

[kaspermarkus]

This IS a must for v0.2 to allow proper support for orca, but a maximum blocking time would probably be a temporary 'solution'.

All the other settingshandlers are also synchronous atm (though with less obvious risks of inifitely blocking the thread) and it seems fixing this requires some rather significant changes to universal - including events fired by each settingshandler and the lifecycle manager listening to them. The integration testing is currently also expecting things to be synchronous, so this would have to be modified as well. imo can put it in, with the suggested max-wait time hack, and a big warning/todo, and then make it a priority to make the handlers asynchronous asap post v0.2 (prob. v0.3 or v0.4).

[javihernandez]

Done!

Note that I have tested this using the branch from GPII/universal#130
Additionally, I had to make a slightly change on linux's gpii.js in order to run the gpii.

-    gpii = fluid.registerNamespace("gpii");
+    gpii = fluid.registerNamespace("kettle");

After that, I can log in and out using the token "orca1". Regarding GPII/universal#130, it contains the transformation stuff for this settings handler, and should be updated properly.

[javihernandez]

BTW, I hope this link helps this pull to be reviewed ;)