[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]