Two naming issues arising from Kettle work
antranig.basman at colorado.edu
Tue Nov 19 14:50:18 EST 2013
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
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,
More information about the fluid-work