Two naming issues arising from Kettle work

[Antranig Basman]

In doing some work recently on improving Kettle (http://issues.gpii.net/browse/GPII-75 / 
http://issues.gpii.net/browse/GPII-245 ), Jura has been creating two new facilities that I think could 
benefit from a public naming discussion.

The first relates to session support for Kettle. The current pull request at 
https://github.com/fluid-project/kettle/pull/6 provides support both for WebSockets-style communication 
using the socket.io package for node.js as well as session support using standard node express middleware. 
Currently there are two kinds of annotations for session-aware requests that I believe are confusingly 
named. In the current pull request these are values of the configuration needSession option, which as far as 
I can see can take on the values "valid", "lazy" and "none".

Yura's description of these options (taken from an outdated diff) is as follows:

"IMHO, there are 2 types of requests and their handlers that deal with sessions.
Ones that need a session but can actually trigger its creation such as a request to /login of a flowManager.
The other type of a request is the one that requires an already existing session and perhaps requires that 
session to be valid based on some sort of criteria. For example the upcoming /update of the flowManager will 
need an existing user logged in session to be handled correctly."

As I understand this description, it might be better reflected in terms of requests which may create a new 
session, and those which expect a session to already exist. A draft suggestion is to have an option named 
"useSession" or "sessionUse" which may take on the values "existing" or "create". The first question of this 
mail relates to this piece of configuration - perhaps Yura can chime in with an updated description of the 
two kinds of session handlers, as well as clarification about the policy for "none" vs a missing value.



The second question relates to what could be described as "new demands blocks". A couple of months ago we 
realised as a result of GPII work that the original FLUID-2881 implementation of demands blocks was a faulty 
framework feature and should be removed in its entirety - especially since the framework has improved 
sufficiently since 2010 that it appeared that all use cases for demands blocks could be handled by 
combinations of other features. Yura succeeded in a series of massive pull requests to remove demands blocks 
in their entirety throughout the GPII and Kettle, which seemed to validate this point of view. However, 
ironically, last week, he ran into one of the prime use cases which had motivated the original 
implementation of demands blocks - a requirement for "multiple dispatch" based on the simultaneous presence 
of two independent context features, in this case, support for sessions, and support for socket.io style 
I/O. I have written up this requirement in a giant JIRA as http://issues.fluidproject.org/browse/FLUID-5212 
which includes all relevant discussion on this issue so far.

As the JIRA reports, the facility is enormously simpler than original demands blocks and can mostly be 
implemented "on the outside" of the current framework without polluting its main options resolution 
pathways. However, it raises a naming issue for grades and options which we will imagine will go back into 
the framework once we are satisfied with the implementation. Yura's early implementation for this can also 
be seen in the https://github.com/fluid-project/kettle/pull/6 pull request.

I am proposing the name "gradeLinkage" for this new facility, which will appear in the grades which relate 
to it. In a verbal conversation with Colin he was unsatisfied with this, and inclined more to words relating 
to "production" etc. Yura's implementation currently uses "linkage" but also has names related to 
"dynamicGrade" which could possibly be removed - since this is a description of a mechanism rather than an 
effect.

For example, right now a grade of "kettle.linkage" holds the record describing linkage, and a grade of 
"kettle.dynamicGrade" is used by a component wanting to "opt in" to the linkage system. I think these two 
names should be more closely related to whatever "common name" we think of to name this system. I think we 
can safely bin the original names related to "demands" which were widely found confusing by framework users. 
The second name will probably be removed from the system once this becomes a framework standard facility 
that operates for all components.

Thanks for your input,

A