Re: [wsrp] Public review comment: extensibility of URLs

[Rich Thompson <richt2@us.ibm.com>]

I can see positives to both possibilities
(Consumer resends or Portlet is required to save them, likely in a session).


I would favor requiring the Portlet
to deal with them as it is not obvious a replay is required to regenerate
the same markup. For example, a queryParameter saying to jump to a certain
page in a search result set likely changes some pointer into the set which
the Portlet will reuse when simply asked to regenerate the markup. Other
cases would cause the Portlet to save the queryParameter as a delta to
its navState and the discussion we are having regarding managing such deltas
would apply. Since the Portlet can manage it and at times won't need to
do anything special to do so, I favor letting the Portlet manage how queryParameters
impact future gM() responses.

Rich

Richard Jacob <richard.jacob@de.ibm.com>

08/15/2006 08:11 AM

To	Subbu Allamaraju <subbu@bea.com>
cc	wsrp@lists.oasis-open.org
Subject	Re: [wsrp] Public review comment: extensibility of URLs

I don't see how this is different to standard navigational
state handling.
The consumer ist not required to replay any nav state which is stored
somewhere in the URL.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                    
                     
                     
          
             Subbu Allamaraju    
                     
                   
             <subbu@bea.com>  
                     
                     
                    
                     
                     
       To 
             08/14/06 06:16 PM    
    wsrp@lists.oasis-open.org          
                    
                     
                     
       cc 
                    
                     
                     
          
                    
                     
                     
  Subject 
                    
                  Re: [wsrp]
Public review comment:   
                    
                  extensibility
of URLs               
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          




In the case of render URLs, is there also a requirement on the consumer
to replay the queryParameters array on future getMarkup requests? If
not, first getMarkup upon URL activation would be different from
subsequent getMarkup requests, and this would break the replayability of
getMarkup requests.

Can you clarify?

Subbu

Rich Thompson wrote:
>
> Proposal updated with alternatives suggested on last week's call.
>
>
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/19634/ExtensionURLs.html

>
>
> This adds the following two alternatives (denoted by the "comment"
> coloring)
>   1. Move the queryParameters[] field to a well-known extension
>   2. Making the format of the Consumer rewriting and template
forms of
> extensibility symmetric
>
> Rich
>
>
> *Rich Thompson/Watson/IBM@IBMUS*
>
> 08/07/2006 07:51 AM
>
>
> To
>            wsrp@lists.oasis-open.org
> cc
>
> Subject
>            Fw: [wsrp] Public review
comment: extensibility of URLs
>
>
>
>
>
>
>
>
>
> Apparently lost in the email server failure at OASIS.
>
> Rich
> ----- Forwarded by Rich Thompson/Watson/IBM on 08/07/2006 07:50 AM
-----
> *Rich Thompson/Watson/IBM*
>
> 08/02/2006 10:47 AM
>
>
> To
>            wsrp@lists.oasis-open.org
> cc
>
> Subject
>            Re: [wsrp] Public review
comment: extensibility of URLs_Link_
> <
Notes://d01ml605/8525626C006C32DD/32547D7F59F9E7E38525613200556E77/A036D4E68C936DB3852571B80041DE80
>
>
>
>
>
>
>
>
>
>
> Here is a proposal to address this issue:
> _
>
__http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/19477/ExtensionURLs.html_

>
>
> Rich
>
> *Richard Jacob <richard.jacob@de.ibm.com>*
>
> 07/27/2006 07:59 AM
>
>
> To
>            wsrp@lists.oasis-open.org
> cc
>
> Subject
>            [wsrp] Public review comment:
extensibility of URLs
>
>
>
>
>
>
>
>
>
>
>
> For 2.0 we extended our WSRP extensions and added the ability to describe
> these.
> Ongoing with this, we anticipated that future proposals can be brought
in
> early/easy before finessing 3.0 based on WSRP 2.0 extensions.
>
> My impression is that having "just" the WSRP 2.0 protocol
payload
> extensions is not sufficient to solve/fully support future proposals.
> One main missing part might  be the extensibility of our WSRP
URLs (and
> symmetrically templates). Our BNF is pretty fixed and not extensible.
> This might prevent furure proposals to work because an extension's
behavior
> can not be triggered via URL invocation.
> Therefor I would propose to extend our URLs in two ways:
> 1. extend the BNF to allow other URL types
> 2. extend BNF to allow custom URL parameters
>
> What needs discussion if we decide to accept the proposal is to decide
how
> Consumer's will  handle URL types they don't know and if/how
Consumers
> propagate unknown URL parameters.
>
> Mit freundlichen Gruessen / best regards,
>
>       Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal Server Development
> WSRP Technical Lead
> WSRP Standardization
> Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
> Email: mailto:richard.jacob@de.ibm.com
>
>
> ---------------------------------------------------------------------
> 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
>
>