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] | [List Home]


Subject: Re: [wsrp-wsia] Question: cloning localized preferences.



This seems to presume that clones will normally only be used in one locale. This may be true for some clones (i.e. once one gets to a clone per user), but I not so sure it should be the presumption.

The current state of affairs would presumably clone the full set of locale-specific values (or none if only customized values are stored per clone ...) so that the preference could get customized for any locale. While this potentially consumes more storage at the Producer, I would prefer to defer optimizing areas such as this until we gain more experience with people implementing, using and extending the spec.

Rich Thompson



Michael Freedman <Michael.Freedman@oracle.com>

04/30/2003 02:15 PM

       
        To:        wsrp-wsia <wsrp-wsia@lists.oasis-open.org>
        cc:        
        Subject:        [wsrp-wsia] Question: cloning localized preferences.



Internally, we have been discussing how we can extend the basic
preference model we have defined to support entity preferences stored in
the locale of the creator.  JSR 168 allows a developer to define
[default] localized preference values. Its possible to conceive that a
producer would want to use the appropriate localized version of these
values when cloning the entity for the first time [say when the
user/page developer places the portlet on a page].  Unfortunately, our
clonePortlet call doesn't pass any information regarding either the
users preferred locale or the consumer's preferred locale for the clone.
Hence, at the moment, this behavior seemingly can only be accomplished
by an extension.  Unfortunately, extensions will diminish use --
particularly in the JSR environment as you don't know what wsrp/jsr
container you may be talking to.   Is syncing up with this JSR 168
capability something anyone else thinks we should address in 1.0 during
the Public review -- or are folks fine on having the JSR 168 concept of
default localized preference values be essentially meaningless in the
remote case?
    -Mike-




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