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

Title: Message

Sasha,

 

First, congrats on the IPO. Is the F2F dinner be on you ;-) 
?

 

I think there has been three issues with URL rewriting by the portal, as 
in option (2):

 

a. JavaScript code is hard/impossible to write - in many cases the URLs 
are constructed only in run-time and hence cannot be written while parsing the 
HTML code. (Let alone having to process also external JavaScript 
code) (Sorry for re-iterating this point)

 

b. Processing time is inherently high, because the portal needs to parse 
the entire stream. (As Alejandro noted)

 

c. It's hard to define how actions embedded in other formats (e.g., 
Flash) can work.

 

So the rationale behind supporting option (4) (rewriting by the portlet) 
in the cases where companies develops a sophisticated portlet that uses one of 
the constructs (a) or (c) above, and also may want to optimize performance to 
eliminate the performance issue in (b) above. (Thing of a MapQuest as one 
example, but also think of trying to sell to a company like Google the idea that 
their output will be re-parsed, performance-wise)

 

It makes sense that SDKs for developing remote portlets should help 
developers, for example by providing a function like an encodeURL(...) that 
takes care of how to embed an action within a URL provided by the portlet, or by 
providing a filter (available both in the Microsoft world and in the Servlets 
world) that does this automatically.

 

This is not to say that option (2) (rewriting by the portal) doesn't have 
its merits (namely, alleviate the need for the portlet to call this function). 
The main reason to support option (2) is to support "simple" portlets (with 
relatively static content). Although, as you noted yourself in a previous 
message, the fact that the protocol uses SOAP as the underlying protocol means 
that portlets can't really be static anyway (they have to process a SOAP 
request, at the least), so given the effort involved in this there's the 
question of whether calling an additional function or using a filter (both can 
provided by a toolkit) are really a bid deal in addition to that 
effort.

 

As to your specific points, assuming we want to support option (4), I 
would induce from your example that the portal should not just transfer URL 
prefixes, but rather URL skeletons, e.g., 
http://www.portal.com?action=(action)&user=sasha, in which the portlet can 
plug in the action identifier. This can also fit the JavaScript example that you 
noted. As for action encoding, we always assume that the action is opaque to the 
portal, so whatever the portlet passes it also receives back. This is somewhat 
ambiguous with identifiers that include URL-encoded symbols (such as %20), so we 
can either disallow them or define the semantics, especially if people want to 
plug them into JavaScript calls as you noted. However, this should be pretty 
easy as JavaScript has a built-in unescape function.

 

If we decide to also support option (2), I agree with you that it's 
better to have both beginning and end markers to make life easier for the 
portal. However, I would still argue that there are many JavaScript scenarios 
where this would still not address the issue.

 

Regards,

Eilon

  

  
-----Original Message-----
From: Sasha Aickin 
  [mailto:] 
Sent: Wednesday, June 05, 2002 
  3:04 PM
To: Sasha Aickin; Alejandro Abdelnur; Michael 
  Freedman
Cc: Chris Braun; WSRP
Subject: RE: Fw: 
  [wsrp][markup] Conf Call Agenda (June5)

  
Sorry to follow up post to myself, but I remembered one other thing I 
  wanted to include.  I think it's important to use tokens to mark both the 
  beginning and end of URLs that are to be rewritten when using (2).  It 
  will make the kinds of URL rewriting I propose below a lot easier (i.e. if 
  using javascript rewriting, the parser won't have to find the end of the URL 
  to insert the close parens).

  
 

  
Sasha.

  
    
-----Original Message-----
From: Sasha Aickin 
    
Sent: Wednesday, June 05, 2002 11:59 AM
To: Alejandro 
    Abdelnur; Michael Freedman
Cc: Chris Braun; 
    WSRP
Subject: RE: Fw: [wsrp][markup] Conf Call Agenda 
    (June5)

    
Alejandro,

    
 

    
I 
    want to reiterate an objection I raised last week against (4) in the markup 
    conference call.

    
 

    
I 
    think that URL rewriting logic should be left to the portal to provide for 
    the maximum flexibility for different web application platforms and kinds of 
    URLs.  If we use (4), then we will be forced to define a rigid way of 
    rewriting URLs that will need to be implemented by each producer.  
    There is a good chance that we would define an URL rewriting algorithm 
    that would be difficult to implement on some platforms or have mistakes 
    (especially when you consider the relatively poor and scattered support for 
    internationalization in URLs).

    
 

    
As 
    an example, imagine that a portlet had an URL, http://portletserver/rewriteme.htm?querystring=value, 
     that needed to be rewritten.  One portal might want to just add 
    that URL to the end of its portal URL, like http://portalserver/portletgateway/http://portletserver/rewriteme.htm?querystring=value.  
    Another portal might want to make the portlet's URL a query string argument, 
    like http://portalserver/portletgateway?portletURL=http%3A%2F%2Fportletserver%2Frewriteme%2Ehtm%3Fquerystring%3Dvalue.  
    Yet another portal might want to make the portlet's URL into a javascript 
    call, like javascript:openPortletURL("http://portletserver/rewriteme.htm?querystring=value").  There 
    are several other ways to rewrite URLs, but I think these examples show 
    that we should not make all portals support the same algorithm for 
    rewriting.  If we use (4), however, we will be forced to do this.  
    (2) gives us more flexibility both in the near term (for different portals 
    to do different kinds of rewriting) and in the long term (for revision 
    when new web application platforms allow for different types of 
    URLs).

    
 

    
Cheers,

    
Sasha.

    
 

    
      
-----Original Message-----
From: Alejandro Abdelnur 
      [mailto:]
Sent: Wednesday, June 05, 
      2002 7:51 AM
To: Michael Freedman
Cc: Chris Braun; 
      WSRP
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