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


Subject: RE: [wsrp] Namespacing revisited


All one needs is a simple pre-processor for 2.
 
For 3, I was not proposing to increase the number of passes but asking if we would want to switch to only using our token as a match "head"?
 
e.g.
 
    wsrp-rewrite?a=b&c=d/   note: ends in "/" not "/wsrp-rewrite"
 
and
 
    wsrp-rewrite-sometoken (as I write this I remember to use second "-" as I have just type a "-" which I remember will be re-written before execution...)
 
regards,
Andre
 
 
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 13 June 2003 16:02
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] Namespacing revisited


#2: I have authored enough nontrivial scripts to know that debugging them in both stand alone and integrated modes is important. While we are not likely to be able to ensure requirement #2 for all scripting environments, we should endeavor to support it for both ECMAScript and VBScript.

#3: The last time we visited this area, the number of parsing passes a Consumer is required to make was a significant issue. Why would it have gone away now?

Rich Thompson



Andre Kramer <andre.kramer@eu.citrix.com>

06/13/2003 10:42 AM

       
        To:        Rich Thompson/Watson/IBM@IBMUS, wsrp@lists.oasis-open.org
        cc:        
        Subject:        RE: [wsrp] Namespacing revisited



For 2, I would favour *not* being able to directly execute so that we ensure that the producer has set the requires re-write flag and that the consumer has found & done the re-write!
 
By the way, I think 3 is not going to be very clean if we use the same token ("wsrp-rewrite") both as a begin / end token pair (url use) and as a stand-alone marker, but could live with such warts.
 
-- Andre
-----Original Message-----
From:
Rich Thompson [mailto:richt2@us.ibm.com]
Sent:
13 June 2003 15:18
To:
wsrp@lists.oasis-open.org
Subject:
RE: [wsrp] Namespacing revisited


Andre makes a good point ... we should step back and agree on the requirements before we spend more time debating solutions.


My original post looked at the following being the requirements for a constant prefix that indicates a namespacing need:

 1. Clarity of the item after indicating need to be namespaced

 2. Ability to directly debug scripts containing namespaced items (functions and variables)

 3. Consumer only needs to execute a single parse on the markup to do all rewriting (URL and namespacing)

 4. Ability of a Consumer to find the end of the token


We should debate whether all these are required and whether anything important has been missed.


I agree that #4 was inadvertent and likely unnecessary. I think the first three have been stated as needed by various communities and therefore should be accommodated.


Rich Thompson


Andre Kramer <andre.kramer@eu.citrix.com>

06/13/2003 05:02 AM

       
       To:        "'Subbu Allamaraju'" <subbu@bea.com>, WSRP OASIS <wsrp@lists.oasis-open.org>

       cc:        

       Subject:        RE: [wsrp] Namespacing revisited




Rich made two assumptions that I'm not sure about:

- the script needs to be executable as is (so we can't use "-" for Java). We can't guarantee this for all scripting langs.

- we need to be able to find the end of the token being re-written (which we can do using urlType=namespace today)

If we give up on the above requirements (for script writing) then a simple reserved token of "wsrp-rewrite-" would do, and be much simpler for script authors to use.

I would then still keep the current urlType=namespace scheme, as this allows better token handling for cases when we do need to find the end of the token (using a space is going to be to fragile in my opinion and I happen to like the ?&= query string format, even if I have to remember the / at the end :-)

regards,
Andre

PS With this we only need the namespacePrefix field to be required for templates / producer writing which it is already.

-----Original Message-----
From: Subbu Allamaraju [
mailto:subbu@bea.com]
Sent: 13 June 2003 04:47

To: WSRP OASIS

Subject: Re: [wsrp] Namespacing revisited

>
> IMO, wsrp-rewrite?.../wsrp-rewrite should be restricted for the purposes
> of constructing URLs.

I second this. The section on URLs would be simpler if the namespacing
issue is dealt with separately.

A reserved token (e.g., wsrp-namespace) for the prefix would be lot
simpler for both portlet developers and consumers.

Subbu

> Using a prefix it's much more readable, #PREFIX#doNothing(). And note
> that the consumer does not need to generate a unique prefix upfront, it
> could handle a special token and resolve the prefix at consumer
> rewriting time.

>
> We could also define a wsrp-namespace$ token to be used as prefix when
> doing consumer rewriting. I wouldn't use the 'wsrp-rewrite$' (as
> proposed by Rich) as this is an overload that may create confusion.

>
> But if I'm doing producer rewriting, I need the namespacePrefix. That's
> way I say it should be a required field.

>
> Alejandro

>
> On Thursday, June 12, 2003, at 10:37 AM, Rich Thompson wrote:

>
>
>     It was brought up on today's call that the primary target for

>     namespacing is not particularly well served by the current design.

>     lets consider a simple JavaScript function:

>
>       function doNothing() {}

>
>     To namespace this today, one has to rewrite it as:

>
>       function

>     wsrp-rewrite?wsrp-urlType=namespace&wsrp-token=doNothing/wrsp-rewrite()

>     {}

>
>     Points made about this rewrite:

>       1. Rather unwieldy and certainly not obvious that the function

>     name was originally "doNothing"

>       2. It is not valid to run as is and this makes testing much more

>     difficult

>
>     The question was raised as to whether we could easily specify a

>     constant prefix token that this author could use that would leave

>     the code both readable and testable while not requiring the Consumer

>     to do two parsing passes. Here is a proposal:

>
>     1. Define "wsrp-rewrite$" as a token indicating that a token

>     requiring namespacing follows

>     2. Require that a space (%20) follow the token to cleanly delimit

>     the end of the token needing namespacing.

>
>     The author would rewrite our example function as:

>
>       function wsrp-rewrite$doNothing () {}

>
>     This almost works. The problem is that JavaScript names can not

>     contain a "-" character. It would work if our delimiting token was

>     changed to wsrp_rewrite so that this example becomes:

>
>       function wsrp_rewrite$doNothing () {}

>
>     and the Consumer URL rewriting expression changes to:

>
>      
>     wsrp_rewrite?wsrp-urlType=value&name1=value1&name2=value2.../wsrp_rewrite

>
>
>     Rich Thompson
>
>

You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php



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