OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [wsrp-interfaces] [wsrp][interfaces] 8/8 Agenda

Hi Carsten,

Regarding your remark: "Supporting extended property editors for portlets on the consumer side is not intended in the current draft.". I do not remember that we decided on this. If I remember correctly we said that the portlets should expose metadata on their persistent properties name/type, and
there should be getProperties/setProperties methods that allows the consumer to create such editors.
Are you referring to something more advanced than this?


-----Original Message-----
From: Carsten Leue [mailto:cleue@de.ibm.com]
Sent: Friday, August 09, 2002 3:55 PM
To: Michael Freedman
Cc: interfaces; wsrp-wsia
Subject: Re: [wsrp-interfaces] [wsrp][interfaces] 8/8 Agenda

Hi Mike.

Responses are added in <cl> tags.

Best regards
Carsten Leue

Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401

|         |           Michael Freedman  |
|         |           <Michael.Freedman@|
|         |           oracle.com>       |
|         |                             |
|         |           08/08/2002 02:46  |
|         |           AM                |
  |                                                                                                                               |
  |       To:       interfaces <wsrp-interfaces@lists.oasis-open.org>, wsrp-wsia <wsrp-wsia@lists.oasis-open.org>                 |
  |       cc:                                                                                                                     |
  |       Subject:  [wsrp-interfaces] [wsrp][interfaces] 8/8 Agenda                                                               |
  |                                                                                                                               |
  |                                                                                                                               |

Both to follow Thomas' lead and because I thought I heard Rich mention
he is mostly focused on the details of what is currently specified vs.
dealing with new issues, I suggest we use the discussion tomorrow to
start to analyze and clarify the .3 draft.  For tomorrow let's focus on
getdescription() and registerconsumer().  I have attached a list of
questions I generated during my review today to stimulate the
discussion.  The goal is to understand what parts are understood and
agreed to vs. still up for discussion vs. isn't addressed yet by the
spec but will likely need to be (i.e. currently pending/deferred).

Conference call details remain the same:
8am PDT
ID: 8814427
Problem:  getDescription(entity) has no way of knowing if the consumer is
registered.  We can get Unregistered attacks.  Is this okay?

It is ok for an unregistered consumer to query the name and initial WSDL
for any producer, so getDescription must work if a null handle is passed
in. In this case we cannot prevent such an attack.
For all other cases the producer can defer the registration context from
the handle, except of the case that the entity is a producer-offered-entity
(POE). This entity has not been created in a registration context, though
might only be accessible in such a context. So it is right, that something
is missing.
I would prefer adding a consumer context as an additional parameter to

Problem:  Don't we want modes/viewstates to be extensible -- i.e. a string
not a bit-vector?
Regarding compability issues with JSR168 that defines these modes as
strings we whould rather use a stringvector

Question:  Why do entities have WSDLs as they aren't services?  I.e. what
is the wsdl url of an entity?
Regarding compability issues with JSR168 that defines these modes as
strings we whould rather use a stringvector

Question:  Why is registrationData a property list?  Why shouldn't the bulk
of this be typed like the entity information?  Put another way, what are
the standard set of properties we define?  Are there some that we perdefine
as required?

The WSDLs will of course point back to the producer (for the standard WSRP
factors). However it is possible that some entities provide more/other
factors (=port types) than others. The WSDLs are the description of these
port types + maybe vendor specific types. From an implementation point of
view the consumer will still talk to the producer via these interfaces but
the entity may indicate which port types the consumer may use with this
entity handle.


Question:  Do we care about allowing the consumer to ask get me the
description of all the entities that this user has access to?  I.e. should
the producer be able to restrict the description based not only on whether
the consumer is registered but also who the user is (what role)?


Still an open question. I will get back later to this.


Question:  What is the intended use of name field defined in EntityType?
Is it needed now that we have entityHandle?

It would be needed as the "short name" (locale dependent) of the entity, so
the consumer portal can display it in a list of available portlets

Question:  Can/should the consumer be able to pass a list of locales it
wants results in?  To minimze lookup/processing/size?
Still open. I would think that this is  not preferable as most portals will
want to display as many locales as the producer supports. Specifying all of
these locales + sublocates would be a huge overhead.

Question:  Do we need to state that the order of the values in the locale
based arrays are tied to the order in the locales fields?

<cl> yes </cl>

Question: Are entityProperties restricted to persistent state -- I assume
not given scope is in the definition?  However don't we need a bunch more
information then this if a consumer is going to render the edit screen for
a producer?  How is this extra information passed?

<cl> The scope of the entityProperties is part of the property itself. They
are just a way for the producer to make some of its state visible for the
consumer. I would think that this is ratrher required in WSIA than in WSRP.

Supporting extended property editors for portlets on the consumer side is
not intended in the current draft.


Question:  Do we need to distinguish between short and full titles?

<cl> The short title would be the name. </cl>

Question: Do we need to allow locale based keywords?

<cl> yes </cl>

Question:  Do we need to allow a consumer to pass "capabilties" to the
getDescription so the producer can "negotiate"/"resolve" its
behavior/description?  I.e. negotiate who manages the persistent store?
Needed for simple producers that don't support registration???

Question:  Should we remove "cacheability" until we get around to defining
caching?  I.e. define those things we know and keep a list of those things
still to be discussed?  I.e. like URL erwrieting etc?

<cl> Rather than having just a cachability flag we should introduce a
caching structure that contains this flag, epiry times, etc. I think that
this information will be required anyway so we can safely define it in the
current spec draft. We also need to determine how much of the caching
information is transport specifc and should thus be defined elsewhere </cl>

Question:  We would like the portlet to return a flag indicating whether it
uses [entity] sessions or not.  Usage:  Portal can distinguish for its page
developers portlets that may perform differently on the page.

<cl> This should be part of the metadata I suppose. If we include it then I
would expect this to be at most a hint and not obligate </cl>

Property data type:

Problem:  Should we overload "Property" definition as we currently do?
I.e. should we have a simpler datatype Property that merely has name, type,
value and a second derived type that deals with scope/required?  I.e.
distinguish between places in the protocol we just want an AVList vs. where
properties are actually being defined?cl

<cl> This may not be necessary as the additional scoping fields are
optional. So a simple name/value pair list will fulfil the type contract

Question:  How are array types passed as "strings" I.e. what is the form of
an array -- comma separated???

<cl> Everything that is not a simple string should be passed as an XML
type. </cl>

Question:  From a WSRP perspective, why isn't the default scope "Entity"
rather then "session"?

<cl> yes </cl>

Question:  What are the valid values of "scope"?

<cl> To be defined, I would say "shared", "session", "entity", "service"

Question:  What does required mean?

<cl> Must have a value supplied. </cl>


Question:  Why do you state "registrationData ... MUST match that which the
Producer declared in response to getDescription()"?  Shouldn't the consumer
only have to supply the "required" elements?  Shouldn't they be allowed to
oversupply here as well i.e. pass there extensions?

<cl> agreed </cl>

Question:  Should the following paragraph page 16:23 read "The Consumer MAY
persistently store the consumerHandle"?

<cl> The consumer handle might lock producer resources.</cl>

ConsumerContext data type:

Question:  Why is userID in here?  Shouldn't it be a User "object" that
contains the ID, roles, and another object that refs to the "profile"

<cl> agreed </cl>

Question: Is "sendTransparentState" needed?  It only seems to apply to

<cl> Because the consumer might want the entityProperties to contain this
state. Again this is rather a WSIA issue I think.</cl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC