[Architecture] Doubts about gpii architecture - Fluid.js

Thu Jan 31 20:41:41 UTC 2013

Hi, Guillem! Thanks for these insightful questions, they are very welcome and show that you have been 
looking at the framework in some detail. I'll give a first pass at answers to start with, and then direct to 
some community resources (I've cross-posted this reply to the main discussion list for Fluid work, 
"fluid-work at fluidproject.org").

1. This is as a result of a framework deficiency/bug which doesn't allow the resolution of demands blocks to 
react to context names which are higher in the grade hierarchy. It is described on this JIRA -
http://issues.fluidproject.org/browse/FLUID-4636
In fact we were discussing this precise bug yesterday, as Yura brought it up at our community meeting (2.30 
EST, to which all are welcome) with the Fluid group. It is certainly an annoyance, since in many cases one 
wants to resolve onto a component purely on the basis that it is a "data source" rather than having to be 
aware of which precise derived class (grade) it is of. This is one of the many bugs that will be resolved as 
part of a big framework work package which is underway - the core branch is named after
http://issues.fluidproject.org/browse/FLUID-4330 but it will also resolve FLUID-4392, FLUID-4636 and 
numerous other issues.

You can track work underway in the branch at https://github.com/amb26/infusion/tree/FLUID-4330 - we expect 
this will be merged into Infusion before the end of February and into GPII shortly thereafter.

2. resolveEnvironment and withEnvironment are functions with a somewhat awkward status within the framework. 
In older framework revisions, they were the only way to achieve certain effects, and although we prefer 
other schemes these days, there is enough old code around in related projects that we can't get rid of them 
very soon. They will not be disappearing for at least several months even though their use is highlighted as 
deprecated. Their use these days has mostly been for constructing integration environments for the purpose 
of testing - for this use case it will be preferable to use the scheme in the new testing framework
http://issues.fluidproject.org/browse/FLUID-4850
This has already been merged into Infusion master, and a node.js compatible version of it appears in the 
branch at https://github.com/amb26/universal/tree/GPII-77 - this will be merged into the GPII master soon 
after we managed to finish work for the 0.1 release which is leading to code freeze.

3. Debugging complex component trees is another issue to which we've devoted a few Fluid community meetings, 
as well as the next one on Feb 6th. The demands block format is designed to be very easy for a tool chain to 
read, but right now the only tools remain human eyeballs :)

The main preferences server is at
https://github.com/GPII/universal/blob/master/gpii/node_modules/preferencesServer/src/preferencesServer.js

It's indeed a little confusing as laid out, but given there are so many options for deploying the different 
GPII components, all of the crucial information needs to be pushed out into configuration - for example, the 
server may or may not be running on the same server as the other GPII components, or even running on the 
local device.

In this case the configurations we support are held in the "configs" directory at the base - for example, 
this is the standard configuration used in the development case:

https://github.com/GPII/universal/blob/master/gpii/configs/fm.ps.sr.dr.mm.os.development.json

This then refers us to this preferences server configuration:

https://github.com/GPII/universal/blob/master/gpii/node_modules/preferencesServer/configs/development.json

This reveals that the preferences server is operated by the standard gpii "URL dataSource" - pointing in 
this case at the filesystem. So in this case the "userGet" request resolves onto the following definition 
for "gpii.dataSource.get"
https://github.com/GPII/universal/blob/master/gpii/node_modules/gpiiFramework/dataSource.js#L292

which in turn is finally handled by the gpii.dataSource.URL.handle method below on line 323.

We hope to soon have better tooling that will aid the developer and user when browsing the framework 
dependencies in cases just as this.

In general since you are asking questions at such a level of detail, it would be great to have you in closer 
contact with the team, and you are very welcome in particular to hang out at our IRC channels fluid-work and 
or fluid-tech -
http://wiki.fluidproject.org/display/fluid/IRC+Channel

There is usually somebody around at most times to chat with who will be happy to talk about such questions 
and give you answers much more quickly.

In general other Fluid resources which are useful for describing the issues you are looking at are -

http://wiki.fluidproject.org/display/docs/Demand+Resolution

and

http://wiki.fluidproject.org/display/fluid/The+IoC+Testing+Framework

Thanks, Guillem, and feel welcome to ask more questions/for clarification - sorry for the late reply

Cheers,
Antranig

On 30/01/2013 02:01, Guillem Serra Autonell wrote:
> Dear All,
>
> I've joined recently Barcelona Digital as the leader of AIL (Active Independent Living) department,
> responsible of Cloud4All related projects among others. Specifically, in Cloud4All we are working on WP103,
> WP302 and WP303.
>
> Regarding WP103 we are thinking in developing an architecture where the context data is pushed from the
> device to the plattform, uses predefined rules and modifies at realtime the user-profile to adapt to the
> device context. Now we are gathering the requeriments, one of our options is using the same gpii
> (nodejs+fluidjs) to develop it.
>
> At this moment we are analysing gpii and fluidjs and some doubts have arisen. I would appreciate a lot some
> help.
>
> Questions:
>
> 1.- Why sometimes you define a "nickname" in addition to defaults("nickname",..)? (for example in app.js)
>
> 2.- Are resolveEnvironment and withEnvironment deprecated? Is there a newer version of gpii? When will it be
> merged to master?
>
> 3.- Debugging gpii using:
>   node --debug-brk gpii/node_modules/gpiiFramework/init.js gpii/node_modules/flowManager/configs/
>
> I am trying to understand all the workflow between different components. I am lost when the application
> access to userGet in preferencesServer after "gpii.dataSource.URL.handle.url". I try to find the
> "userSource.get" method in "userGet.js" and where is the actual method and where it's defined but I am quite
> confused at this point.
>
> Sorry for the newbie questions.
>
> --
> *GUILLEM SERRA AUTONELL
>
> **Manager**
> R&D Health
>
> BARCELONA DIGITAL TECHNOLOGY CENTRE
> **www.bdigital.org <http://www.bdigital.org/>*
> 	*Phone**.*+34 93 553 45 40  Ext. *2224**
> M.*636 45 04 41*
> **TW:*@norbak*
> *gserra at bdigital.org <mailto:gserra at bdigital.org>
> <http://twitter.com/bdigital> 	<http://www.linkedin.com/groups?gid=3755107&trk=hb_side_g>
> <http://www.youtube.com/user/BarcelonaDigital?feature=mhum> 	<http://www.flickr.com/photos/barcelonadigital/>
>
> <http://www.bdigital.org/> 	<http://www.acc10.cat/tecnio> 	
> *In Barcelona
> (headquarters):*
> Media-TIC building.
> C/ Roc Boronat 117, 5th floor
> 08018 Barcelona (Spain)
> Phone(+34) 93 553 45 40
> Fax (+34) 93 553 45 41	*In Lleida:*
> Scientific and Technological Agro-food Park.
> Gardeny Park.
> ICT building, ground floor
> 25071 Lleida (Spain)
> Phone(+34) 973 19 36 60	*In Girona:*
> Scientific and Technological
> Park of Girona University.
> Narcís Monturiol building.
> C/ Emili Grahit, 91
> 17003 Girona (Spain)
> Phone(+34) 972 41 64 78
>