AW: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: capabilities

["Döring, Markus"]

John,
all changes going on with TAPIR right now are really only changes in terminology or removing inconsistencies we did not detect before we started the documentation and final implementation.


But nevertheless I would support your request. Especially from the implementation side of view this is a trivial change to the code. So why dont add it? Just some additional thoughts:


- Ive added a "simulation" mode already to my code where no SQL gets executed but just logged. So you can test configurations without risking sending off killer statements. Thats similar to logOnly I guess, returning nothing but diagnostics. What would you suggest to be returned for a logOnly request? just the empty TAPIR envelope? Nothing? <OK>?

- would this log-only request not be needed for all requests? at least for inventories? So it would be easiest to have a new logOnly parameter in the header or "request element" just after the header? something like <search logOnly="true">



-- Markus
  

> -----Ursprüngliche Nachricht-----
> Von: pywrapper-devel-bounces at lists.sourceforge.net 
> [mailto:pywrapper-devel-bounces at lists.sourceforge.net] Im 
> Auftrag von John R. WIECZOREK
> Gesendet: Montag, 17. Juli 2006 23:30
> An: Renato De Giovanni
> Cc: pywrapper-devel at lists.sourceforge.net; tdwg-tapir at lists.tdwg.org
> Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: 
> capabilities
> 
> A little off topic, but it occurs to me that a great deal of 
> work is still ongoing with TAPIR, which suggests to me that 
> it may be warranted to re-state my request for a simple 
> message type - a log request. This request would be the same 
> as a search request, except that the caller doesn't need a 
> response. Providers would use this type of request to log 
> data usage if the data were retrieved from a cache elsewhere. 
> I remember talking about this in Berlin, at which time there 
> was supposed to be a feature freeze. Clearly we've gone 
> beyond that, so I'm requesting it again. 
> 
> 
> On 7/17/06, Renato De Giovanni <renato at cria.org.br> wrote:
> 
> 	Hi,
> 	
> 	If I remember well, the "view" operation was re-included in the
> 	protocol just to handle query templates, especifically 
> for TapirLite
> 	providers. So if someone wants to query a provider using some 
> 	external output model that should be dynamically 
> parsed, then the
> 	"search" operation must be used instead (using either 
> XML or simple
> 	GET request). View operations are really bound to query 
> templates,
> 	and they are not allowed to specify "filter" or 
> "partial" parameters.
> 	--
> 	Renato
> 	
> 	On 17 Jul 2006 at 21:26, "Döring, Markus" wrote:
> 	
> 	> I was just about to edit the schema and realizing 
> that output models 
> 	> are only specified for searches. but what about 
> views? they use
> 	> query templates, yes. but only the ones listed in 
> capabilities? we
> 	> should have dynamic ones here as well I think. And 
> they link back to 
> 	> static/dynamic models.
> 	>
> 	> So should models maybe become a seperate section not tight to
> 	> search/view operations? I am going to modify the 
> schema nevertheless
> 	> already to accomodate the changes below - ignoring 
> views for now. 
> 	>
> 	> Markus
> 	
> 	_______________________________________________
> 	tdwg-tapir mailing list
> 	tdwg-tapir at lists.tdwg.org
> 	http://lists.tdwg.org/mailman/listinfo/tdwg-tapir 
> <http://lists.tdwg.org/mailman/listinfo/tdwg-tapir> 
> 	
> 
> 
>