Re: [wsrp] getResource question

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

The original proposal for the url parameters
for getResource had parameters serving multiple uses depending on which
technique was being used to fetch the resource. People thought this added
complexity for the reader and set a direction for unique identifiers. At
the time it was also noted that this allowed portlet URLs to provide identifiers
for both forms of resource fetching such that the Consumer could be allowed
to choose which to use. The wsrp-preferOperation parameter was added to
provide guidance on the Portlet's preference if both mechanisms were supported.

Before people debate your proposal to
step back toward intermixing the two means for fetching a resource, I would
ask that a couple of questions:
1. There have been some comments about
Consumers being required to support getResource in order to be v2 compliant.
If we think that is true, do we really need to allow resource URLs to separately
specify how to use both mechanisms?
2. If the answer to #1 is no, is there
a reason not to change the semantics of preferOperation to a directive
(useOperation) and drop the resourceID (e.g. have the wsrp-url parameter
describe the resource for both mechanisms)?

Rich

Subbu Allamaraju <subbu@bea.com>

05/27/05 02:41 PM

To	wsrp <wsrp@lists.oasis-open.org>
cc
Subject	Re: [wsrp] getResource question

Rich Thompson wrote:
> 
> The resolution when this was last discussed runs counter to your 
> proposal, namely:
> 
> - Keep the http proxy (wsrp-url) and getResource (wsrp-resourceID)
forms 
> of fetching resources independent of each other.

Could you elaborate this further?

> - Allow Portlets to specify both forms or resource fetching (assist
> Consumers that only support one) with guidance on which is preferred.

Not sure if this is possible. I think the choice between these two 
depends on whether the producer needs portlet's state or not, and 
whether the resource is URL addressable.

> I see your point in theory (URLs are allowed to have any length),
but 
> not in practice (most browsers limit URLs to 4096 characters). If
a 
> Producer wishes to supply URL-addressed resources via getResource,
I 
> don't see the problem in using the resourceID to either contain or
> reference the URL.

For the spec, it is clumsy to use IDs to pass URLs. Since there is an 
explicit use case for serving URLs over the getResource operation (that
was the original use case for getResource), we should provide a cleaner
solution.

BTW, when last checked, IE failed to process URLs longer than about 1000
characters, while Firefox processed much longer URLs (>11000 chars).

Subbu


> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 05/27/05 01:46 PM
> 
>                  
> To
>                  wsrp
<wsrp@lists.oasis-open.org>
> cc
>                  
> Subject
>                  Re:
[wsrp] getResource question
> 
> 
>                  
> 
> 
> 
> 
> 
> Such a change would imply a Consumer could extract the wsrp-url
> parameter from the URL and send it as a resourceID to the producer.
It
> is somewhat awkward to do so. A cleaner solution would be to change
the
> ResourceParams struct to
> 
> ResourceParams
> [O] ID                  
resourceID
> [O] string                
url (language to say that this field is the 
> wsrp-url parameter)
> ...
> 
> and add a conformance statement that clarifies that the Consumer MUST
> supply one of these fields (but not both) depending on whether the
> Producer specified a wsrpUrl or a resourceID parameter in the URL.
> 
> I also noticed that the Sec 10 is not clear if a resource URL can
> specify both a wsrp-url and a resourceID. We should further clarify
that
> "If the resource is not URL-addressable, Consumers MUST/SHOULD
use the
> resourceID parameter to specify an ID to retrive the resource. Producers
> MUST NOT specify both a wsrp-url parameter and a resourceID parameter
in
> the same URL."
> 
> Regards,
> Subbu
> 
> Andre Kramer wrote:
>  > Web browsers do in practice have a limit on the size of
URLs which
>  > argues for the max length. However, I now see your point
and agree we
>  > could make the type of the resource identifier xsd:string.
>  >
>  > Regards,
>  > Andre
>  >
>  > -----Original Message-----
>  > From: Subbu Allamaraju [mailto:subbu@bea.com]
>  > Sent: 27 May 2005 16:19
>  > To: wsrp
>  > Subject: Re: [wsrp] getResource question
>  >
>  > I thought about that possibility, but I don't think it
is valid. WSRP
>  > spec restricts IDs to be of less than 4096 chars (or less,
depending on
>  > how many bytes it takes to store a char), where as URLs
have no such
>  > restrictions in the spec.
>  >
>  > That's why I brought up the need for some persistence (atleast
in
>  > memory) for wsrpUrl <-> resourceID mapping.
>  >
>  > Regards,
>  >
>  > Subbu
>  >
>  > Andre Kramer wrote:
>  >  > I don't think we need to introduce a notion
of some sort of persistent
>  >  > resourceID. The resourceID parameter is just
a way to point to a
>  >  > resource and it should be perfectly legal (and
normal) to use a URL
>  >  > string as a resourceID. From the point of view
of the protocol and the
>  >  > consumer a resourceID is just a URI (a unique
identifier for a
>  > resource)
>  >  > - we do not describe or mandate the mapping
mechanisms.
>  >  >
>  >  > Regards,
>  >  > Andre
>  >  >
>  >  > -----Original Message-----
>  >  > From: Subbu Allamaraju [mailto:subbu@bea.com]
>  >  > Sent: 27 May 2005 15:01
>  >  > To: wsrp
>  >  > Subject: Re: [wsrp] getResource question
>  >  >
>  >  > Andre Kramer wrote:
>  >  >  > Yes, URL-addressable resources need
their addresses (URLs) mapped
>  > into
>  >  >  > the resourceID resourceParam. Remember
that these (resourceIDs)
>  >  >  > themselves get put on URLs in the
markup which is why I though it
>  >  >  > clearer as well as more general to
not make them explicitly URLs or
>  >  > even
>  >  >  > URIs (even though these are likely
to be the common cases).
>  >  >
>  >  > My main concern is that, a majority of resources
are static and
>  >  > therefore are URL addressasble. Web servers
and app servers don't help
>  >  > map static resources to resourceIDs.
>  >  >
>  >  > We can encourage non-URL addressable resources
to use the notion of
>  >  > resourceID, but it is somewhat inconvenient
to map static resources to
>  >  > resourceIDs. There is some cost to managing
resourceIDs (perhaps
>  >  > persistently), and this discourages producers
from supporting the
>  >  > getResource operation.
>  >  >
>  >  > I find that it is more natural for producers
to use URLs for
>  >  > URL-adressable resources, and resourceIDs for
other resources (such as
>  >  > some bank statement generated from user's query),
and that the
>  >  > getResource should provide for both.
>  >  >
>  >  > Regards,
>  >  >
>  >  > Subbu
>  >  >
>  >  >
>  >  >
>  >  >  >
>  >  >  > Regards,
>  >  >  > Andre
>  >  >  >
>  >  >  > PS. Wish we had WS Addressing endpoint
references ...
>  >  >  >
>  >  >  > -----Original Message-----
>  >  >  > From: Subbu Allamaraju [mailto:subbu@bea.com]
>  >  >  > Sent: 26 May 2005 22:42
>  >  >  > To: wsrp
>  >  >  > Subject: [wsrp] getResource question
>  >  >  >
>  >  >  > I've a question on the getResource
operation.
>  >  >  >
>  >  >  > AFAIR, the primary use case for this
operation was to allow
>  > Producers
>  >  > to
>  >  >  >
>  >  >  > serve resources over SOAP instead
of HTTP, which was not possible
>  > with
>  >  >  > WSRP1.0.
>  >  >  >
>  >  >  > But it is not clear how a WSRP2.0
producer can serve
>  > URL-addressable
>  >  >  > resources via the getResource operation
without somehow mapping
>  > those
>  >  >  > addresses into resourceIDs.
>  >  >  >
>  >  >  > My question is, why is not there
a wsrpUrl parameter in the
>  >  >  > ResourceParams structure? The lack
of such a parameter may impact
>  > the
>  >  >  > motivation for supporting this operation
in producer/consumer
>  >  >  > implementations.
>  >  >  >
>  >  >  > Can someone clarify?
>  >  >  >
>  >  >  > Thanks
>  >  >  >
>  >  >  > Subbu
>  >  >  >
>  >  >  >
>  > ---------------------------------------------------------------------
>  >  >  > 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
>  >  >  >
>  >  >
>  >  >
>  >  > ---------------------------------------------------------------------
>  >  > 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
>  >  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  > 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
>  >
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 


---------------------------------------------------------------------
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