[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? Yossi. -----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 877.302.8255 303.928.2609 ID: 8814427 getDescription: Problem: getDescription(entity) has no way of knowing if the consumer is registered. We can get Unregistered attacks. Is this okay? <cl> 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 getDescription </cl> Problem: Don't we want modes/viewstates to be extensible -- i.e. a string not a bit-vector? <cl> Regarding compability issues with JSR168 that defines these modes as strings we whould rather use a stringvector </cl> Question: Why do entities have WSDLs as they aren't services? I.e. what is the wsdl url of an entity? <cl> Regarding compability issues with JSR168 that defines these modes as strings we whould rather use a stringvector </cl> 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? <cl> 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. </cl> 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)? <cl> Still an open question. I will get back later to this. </cl> Question: What is the intended use of name field defined in EntityType? Is it needed now that we have entityHandle? <cl> 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 </cl> Question: Can/should the consumer be able to pass a list of locales it wants results in? To minimze lookup/processing/size? <cl> 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. </cl> 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. </cl> 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 </cl> 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" </cl> Question: What does required mean? <cl> Must have a value supplied. </cl> Registration: 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" information? <cl> agreed </cl> Question: Is "sendTransparentState" needed? It only seems to apply to setProperties. <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