Hi Markus,
Thanks for your reply.
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?
I was thinking that the client on start up might want to register its rule
when it first send a request. Or the other way round, the content server
(perhaps a CDN) upon receiving the first request from a particular user or
domain (which have not connected to it before), might want to register its
rules with the proxy. Perhaps a on-the-fly secure file transfer would do
the job too, now that you mention it.
(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.
It is my intention to develop a last-hop gateway for QoS streaming. But it
is now still in the "dreaming " stage, so I do not yet have solid/clear set
of requirements. I belive the OPES working group is most relevant to the
work I am on. Thus i hope to know the work items of the group regarding
aspects on QoS.
Thanks.
Chan Wah Ng.