Hi Chan Wah,
(1) According to the OPES architecture draft, IRML loading is done via
secure file transfer.
This is one possibility, there are other mechanism that might be
(more?) suitable. We need to discuss and define the requirements for
rule loading and then decide on an appropriate mechanism/protocol(s).
If it makes sense, we should re-use existing approaches and standards.
Do I interpret your comments correctly in a sense that you consider
dynamic downloading of rules a requirement? If so, what timing do you
have in mind, i.e. how fast should a new rule be reflected in
corresponding OPES devices? Are you thinking in terms of seconds,
minutes hours? Maybe you could also give some examples that would
motivate such a requirement.
Doesn't that limits the rules to be loaded statically?
Why? A secure file transfer can be triggered at any time, whenever it
is necessary to dynamically download or update a rule.
There may be situations where the clients or content providers
wants to attach a rule on run time.
Do you have a specific example in mind?
(2) Bandwidth/Content adaptation has been quoted in various drafts as an
example OPES services. IMHO, that requires QoS information to be effective.
Is there any consideration in expanding the IRML property names to include
QoS parameters as well? (Currently, IRML Draft defines "request-line",
"reponse-line", "request-path", "user-id", "system-date", and
"system-time").
There might be a need to include more general "environmental"
conditions in the rule language, for example the bandwidth and/or load
issue you mentioned, but also things like time, date or general
timers. Maybe there's a place for rules like "if the local load on the
system is low, execute the service locally, otherwise do a remote
callout" or similar. The design goal of IRML is to allow for such
conditions, although the current focus was on HTTP based conditions.
As we better understand the requirements, we certainly will consider
these issues.
-Markus