Re: [wsrp] getResource question

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

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

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.

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