[Architecture] Doubts about gpii architecture - Fluid.js
Guillem Serra Autonell
gserra at bdigital.org
Fri Feb 1 06:25:00 EST 2013
Thanks for your detailed response! Actually, I prefer your lateness if
there is accompained with this kind of detail.
I am studying the gpii with new eyes now. I'll connect to IRC if I have
more questions (fluid.js seems wonderful but it is quite strange at the
2013/1/31 Antranig Basman <antranig.basman at colorado.edu>
> 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 -
> 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<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<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
> 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<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
> 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:
> This then refers us to this preferences server configuration:
> 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
> 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 -
> 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 -
> Thanks, Guillem, and feel welcome to ask more questions/for clarification
> - sorry for the late reply
> 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
>> 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
>> 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
>> 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*
>> *gserra at bdigital.org <mailto:gserra at bdigital.org>
>> <http://twitter.com/bdigital> <http://www.linkedin.com/**
>> <http://www.bdigital.org/> <http://www.acc10.cat/tecnio>
>> *In Barcelona
>> 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
> Architecture mailing list
> Architecture at lists.gpii.net
*GUILLEM SERRA AUTONELL
BARCELONA DIGITAL TECHNOLOGY CENTRE
*Phone**. *+34 93 553 45 40 Ext. *2224**
M. *636 45 04 41*
*gserra at bdigital.org
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Architecture