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,
"[email protected]").
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*
*[email protected] <mailto:[email protected]>
<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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
