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 <>
05/27/05 01:46 PM
To
wsrp <>
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:]
> 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:]
> > 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:]
> > > 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
