Re: query by reference

On Nov 16, 2005, at 8:55 AM, Seaborne, Andy wrote:

> Probably OK - as long as it's a third way and not a replacement for  
> POST which was mentioned in the past.

Well, as I said, it makes a *third* way, so I'm obviously not  
proposing it as a replacement for POST.

> There are some issues that arise with this (and incidently, much of  
> this applies to graph specification in the protocol and FROM as well).
>
> 1/ A query processor may not be able to issue GET requests to pull  
> the query.  A common data centre architecture is front-end web  
> servers directing requests to backend machines.  The back end  
> machines are firewalled off and only talk to the front end  
> processors and other backend systems.  They can't reach out to the  
> web (nor be reached which is the real point).

Sure. Presumably there are lots of system designs that don't allow  
for one or another things to happen. Obviously if this is the  
architecture someone deploys, then query-uri won't be supported. That  
seems identical to a situation whereby SOAP isn't supported because,  
say, people don't deploy it. Constraints constrain, after all. ;>

> 2/ POST is still needed if the client is inside a firewall,  
> indirection for a large query is not always possible.

I don't understand this.

> 3/ Presumably, the "query-uri" can be deferenced by any means,  
> including naming a query already on the server?  This is mainly a  
> spec language issue. This is a useful feature - it's a light-weight  
> form of prepared query.

So in this case query-uri would be a relative URI?

I haven't thought about that, but it seems fine to me.

>> I don't believe this opens any additional security or  
>> implementation  burdens since:
>> - we already allow arbitrary URIs to be deref'd to load data
>
> If the request is transmitted over SOAP, isn't it odd that the  
> query engine is doing a GET?

Why odd?

> What error conditions will be signalled back to the client on fetch  
> errors?

I don't know; we can add another error to the protocol spec. There  
may be a relevant error in the HTTP spec re:  HTTP proxies. Seems to  
me that this is a very primitive form of web proxying.

Cheers,
Kendall

Received on Wednesday, 16 November 2005 14:58:10 UTC