[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp] getResource question
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]