I agree that some/many consumer may provide the developer a way to
relate two distinct names, I am merely introducing another use case
that would allow producers to do so [and therefore take advantage of
auto-wiring capabilities in the consumer]. This type of data is easily
captured in non-code meta data -- hence one can envision a producer
administrator updating the meta data without updating the
producer/version when [auto] interactions with other producer/portlets
is desired.
-Mike-
Rich Thompson wrote:
Your two questions are sufficiently
different that I would suggest splitting the discussion into two
threads.
Relative to aliasing, I see the
value,
namely; if the portlet developer/deployer knows that the semantics of a
particular property is equivalent to another well-known property, it
would
certainly help the Consumer to make this available in a computer
processable
form. The question I would raise is whether the Producer is going to be
the locus of such information often enough to warrant defining a field
for it. I suspect that most often it will be the page developer
discovering
this as the described semantics of the two properties are compared.
Rich
A couple of questions/issues I came up with post F2F
on
Transient properties:
1. Should
the meta data that describes transient properties be improved to
support
a notion of aliasing?
Is there value in distinguishing between the name the portlet receives
the transient property as and the set of [coordination] names that
identify
this property to the consumer? The use case is two [sets of] portlets
that are developed independently each with their own
namespace/vocabulary
for properties sometime afterwards understanding that coordination
could
also occur between them because the property [semantics] are the same.
Current model requires the one/both to change its implementation
with potential backwards compatibility impacts. We could however
offer another field in the TransientPropertyDescription that is an
array
of aliases which identify other identities of the same property.
Should
we add this to our 2.0 design?
2. By
defining a specific/known duration for consumerSession scope can we
make
this a required feature in 2.0?
My understanding from our F2F discussions is that producers couldn't
rely
on transient properties to hold internal state because though we
required
support for this feature we said it was valid for the consumer to claim
support by merely always sending/representing a null value [i.e. value
always out of scope]. I think this is a severly restricts the value
of transient properties and makes them more akin to
NavigationalParameters.
Since all we are defining is the consumerSession Scope and that we
though unstated this scope is implied/must exist in WSRP 1.0 to support
managing portletSessions can we stengthen our proposal by requiring
that
a transientProperty of consumerSessionScope must be maintained for the
exact amount of time that the consumer maintains the portlet's session
assuming that portlet session has an infinite lifetime from the
perspective
of the producer? [I.e. portlet session timeouts aren't a factor in
this]. By equating this transientProperty scope to the same scope
that the consumer manages portletSessions on we create an equivalence
between
the management of public session state and opaque session state meaning
the portlet can now depend on the public state.
-Mike-
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|