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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


Subject: Re: Fw: [wsrp][markup] Conf Call Agenda (June5)



PEEP. I'm not participating in the markup discussions on regular basis, so I've been trying to catch up with the URL rewriting thing last week and I've checked with Chris on the current status of the dicusscion.

My understanding was that the scenario 4 (the producer does the rewriting) was still to be evaluated.

From Mike's email I understand that scenario 2 (the portla does the rewriting) would be the way to go.

I was planning to join the conf call today.

Following are my thoughts on the scenarios (2) and (4).

Regards.

Alejandro

steps of a request:

(a) consumer prepares for call,
(b) consumer calls producer,
(c) producer prepares content,
(d) consumer receives content,
(e) consumer prepares content
(f) consumer presents consumer to client.


URL rewriting related activity for scenario (2):

 (a) nothing
 (b) nothing
 (c) producer uses set of standard tokens to create content
 (d) nothing
 (e) consumer determines URLs, parses content and replaces tokens with URLs
 (f) nothing

URL rewriting activity for scenario (4):

 (a) consumer determines URLs
 (b) consumer sends URLs as part of the call
 (c) producer uses received URLs to create content
 (d) nothing
 (e) nothing
 (f) nothing


neutral for (2) and (4):

from the producer perspective (c) is equivalent for both scenarios, the only diffferent is that (2) uses a set of predefined tokens and (4) uses a set of URLs when creating the portlet content. i do not see there a performance impact or complexity in the producer if  using scenario (2) or (4).

pros for (2):

 (a), (b) no need to do any up front work, call payload smaller.

pros for (4):

 (e), no content parsing needed. content can be streamed back to client as a blob.

cons for (2):

 (e), consumer has to parse received content and replace tokens with URLs.

cons for (4):

 (a), consumer has to determine URLs, most likely will be a fix & predetermined set of URLs.
 (b), consumer has to send the ULRs set from the consumer to the producer thus increasing the size of the payload.


my conclusion:

considering that the number of tokens we are talking is small (about 4)  i see the scenario (4) (a) and (b) steps as much ligther weight than the scenario (2) (e) step.



Michael Freedman wrote:
Chris,
   I apologize but I have a conflict tomorrow and won't be able to call in personally.  Good news however is that I didn't hear a peep from either the JSR group or internally in requiring the portal to support URL rewriting.  I.e. it looks like there are no objections to the consensus choice voiced last week.  The one thing that was mentioned and I think is a good idea is that all content responses must include an indication that URL rewriting is required otherwise the portal is free to assume that it does not.  I.e. a mechanism to indicate whether or not URL rewriting/substitution processing needs to run on this response with the default being don't run/process the response.  As this response is coming in a SOAP response, this should be easy -- as its just another return parameter along with the content.
   As for URL/Link types:  The one thing I would like to throw into the mix are Portal URLs.  At times a portlet may want to embed a reference (in its content) to well known Portal locations;  for example "home".  Shouldn't we use our URL rewriting mechanism to manipulate these types of links? i.e. allow a URL rewrite token to be followed by a token indicating the portal location; something like portal:xxxx where xxxx is a portal defined location token (e.g. portal:home)?

     -Mike-

Chris Braun wrote:

 

Wednesday June 5, 12:00PM EDT

To join this conference:

For quick access, go to https://bowstreet.spiderphone.com/27914907
(This link will help connect both your browser and telephone to the call)

OR dial 1 (866) 633-2978 or +1 (646) 485-9300 and enter 2791 4907

 
Markup members, Here is the agenda for next weeks conference call.  The conference call dial in info will follow, but it's the same as usual. Agenda: 1. URL Rewriting2. Visual Themes CSS Classes  Items to be covered (to help guide the conversation) 1. URL Rewriting     1.1 Conclude Scenarios        1.1.1 Try to come to a consensus as to which scenario/scenarios we should use.     1.2 Possible URL Types (What is a Link?) 
        1.2.1.Fully qualified URL – Nothing needs to be done at the consumer

        1.2.2.Action links – URL rewritten so the consumer can intercept the action and forward the action onto the portlet service via soap.

        1.2.3.Proxy resource links – rewritten so the consumer can intercept the resource request.The resource can then either be pulled from an internal consumer cache or retrieved via http.

        1.2.4.Relative URI – For relative URIs the producer sends the consumer the Base URI to be used when generating relative references.

        1.2.5.Actions to other WSRP services?

    1.3 Discuss possible grammars for each URL type.

2.  CSS Classes

    2.1 Table - 

        2.1.1 Recap 

        2.1.2 Do we need a custom class to describe wsia-table for backgrounds, fonts, etc? 

    2.2 Sections

    2.3 Forms

    2.4 Menus

    2.5 Portlet

 




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


Powered by eList eXpress LLC