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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

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


Subject: Re: [wsrp-wsia] v0.90, comments and questions


Rich,

Some more comments embedded <aa>...</aa>

Alejandro

> 
> 5- P20/L1-3
> I need somebody to refresh my memory. When did we agree on 255 as a
> maximum handle length?
> <rt>Nov. F2F</rt>

<aa>I was under the impression this was a close call and we would do an 
email follow up.</aa>

> 7- P22/L1
> MarkupType name for this type is misleading.
> <rt>I've started to rename it several times, but never came up with a
> better name ... need a suggestion and then I'll open a change request</rt>

<aa>The name is not good. I would open an issue just to be sure we 
address this one.</aa>

> 8- P22/L19
> The portlet description should a ModelDescription element, shouldnt it?
> <rt>We had decided not to automatically include this in the
> PortletDescription (issue #120)</rt>

<aa>Got it, I've found out that is being returned in the 
PortletDescriptionResponse. I'm fine with it.</aa>

> 10- P24/L19-23
> Is this section saying that the value is always and array, and it could
> be of generic objects or just string? I assume so, but it is not clear
> to me.
> <rt>It is trying to say that in general it is an array of objects. Since
> we expect it to frequently be a single string, an alternate form for
> passing this simpler type is provided.</rt>

<aa>If I understand correctly the two options are Object[] and String. I 
woul request adding a 3rd alternate, String[].

Please open an issue for this one.</aa>

> 11- P25/L24
> ModelDescription does not convey the meaning of this type, I would
> suggest something like PropertiesDescription.
> <rt>It is used to describe the model of something. Current two uses are
> Producer-specific registration data and Portlet-specific properties.
> 

<aa>PropertyModelDescription?</aa>

> 14- P36/L12-16
> What is the purpose of markupBinary ?
> <rt>Carrying markup types that do not map into a string field. Examples
> include an image and a DIME attachment (using currently proposed
> mechanisms)</rt>


<aa>A portlet generates fragments, how an image or a DIME attachment 
would be aggregated in a portal page?

Please open an issue for this one</aa>

> 17- P40/L26-33
> In the case of a allUsers cache, the expiration mechanism is not
> clear. It says that if the MarkupParameter change the cache must be
> invalidated. Which one? How different locales are handled? Different
> markups?, etc ?
> <rt>I read this to say that the markup may be cached and supplied to all
> users who would be using the same MarkupParameters. MarkupParameters does
> include locale, markupType, etc.</rt>

<aa>The spec reads "When the MarkupParams structure supplied for 
generating the markup changes, the Consumer MUST treat the cached markup 
  as if the expires duration had already elapsed". From this I 
understand that the consumer will discard the cached markup if something 
changes in the MarkupParameters of one user. In the case of  *allUsers* 
cache this means that the cache will be discarded for all the other 
users too, regardless if the changed their MarkupParameters. Probably 
the intention here was to say that the cached markup it is not cache hit 
for that user anymore and it may be another [already] cached markup that 
may be a cache hit. Or if there is not, the portlet may be called and 
the returned markup will be stored keyed out with the new 
MarkupParameters for this user. And all the other users that still have 
the original MarkupParameters keep hitting the original cached markup.

Please open an issue for this one.</aa>

> 19- P44/L1-15
> I dont agree with the recommendation on not swapping from non-secure to
> secure and vice versa. There are app servers and web servers that
> support this. The Servlet spec allows implementations to support this.
> Also, if we do not recommend this swapping, why do we provide the secure
> url-templates when we are insecure and vice versa?
> <rt>secure to non-secure would be a security violation. The non-secure to
> secure is guidance ... if the Consumer "knows" it will work for the
> Producer, this direction of movement is less problematic.</rt>

<aa>I don't see secure to non-secure as a violation. For performance and 
scalability reasons you do not want to do secure all the time but only 
when you are rendering confidential data. Web apps do this all the time.

Please open an issue for this one</aa>

> 20- P48/L17-19
> How is solo different from maximized? I mea, practically, what would the
> consumer or producer do differently?
> <rt>Examples raised included other portlets appearing minimized in
> maximized windowState vs not appearing in solo windowState.</rt>

<aa>Isn't it up to the portal to decide how to present a maximized portlet?

Please open an issue for this one</aa>





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


Powered by eList eXpress LLC