<div>I appreciate that you will consider this request. I always thought it would be trivial to implement. Your simulation mode sounds very much like what I had in mind. I hadn't thought it necessary to get a response from a log request, but if there was a simple response, it could be used as a ping, or it could be used to retry logging until the provider did respond. So, something like <log request received>. I think the addition of logOnly attribute is a good one, and could apply to every request type.
</div>
<div> </div>
<div>Javi, I don't disagree that portals SHOULD log the data usage, especially to cover the situations where a provider doesn't respond. I also think that having the information logged at the provider is a responsible course of action, since they will have immediate access to the usage statistics that way. It will be much easier for a portal builder to send log requests than it will be to build the infrastructure and interfaces to logs, therefore it is more likely to actually get done.
<br><br> </div>
<div><span class="gmail_quote">On 7/18/06, <b class="gmail_sendername">Javier de la Torre</b> <<a href="mailto:jatorre@mncn.csic.es">jatorre@mncn.csic.es</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I am not sure about this,<br><br>I still think that portals should be gathering this data and making<br>it available for data providers...
<br><br>But in any case if you like it then I agree with MArkus that the best<br>is to include another parameter in the operationRequestGroup.<br><br>I havent checked but what happens if you do an extension there with<br>
an attribute that is implementation specific? A qualified attribute.<br>Will this still validate against our schema? You were discussing<br>about qualification of attributes before no?<br><br>Javi.<br><br>On 18/07/2006, at 10:41, Döring, Markus wrote:
<br><br>> John,<br>> all changes going on with TAPIR right now are really only changes<br>> in terminology or removing inconsistencies we did not detect before<br>> we started the documentation and final implementation.
<br>><br>><br>> But nevertheless I would support your request. Especially from the<br>> implementation side of view this is a trivial change to the code.<br>> So why dont add it? Just some additional thoughts:
<br>><br>><br>> - Ive added a "simulation" mode already to my code where no SQL<br>> gets executed but just logged. So you can test configurations<br>> without risking sending off killer statements. Thats similar to
<br>> logOnly I guess, returning nothing but diagnostics. What would you<br>> suggest to be returned for a logOnly request? just the empty TAPIR<br>> envelope? Nothing? <OK>?<br>><br>> - would this log-only request not be needed for all requests? at
<br>> least for inventories? So it would be easiest to have a new logOnly<br>> parameter in the header or "request element" just after the header?<br>> something like <search logOnly="true">
<br>><br>><br>><br>> -- Markus<br>><br>><br>>> -----Ursprüngliche Nachricht-----<br>>> Von: <a href="mailto:pywrapper-devel-bounces@lists.sourceforge.net">pywrapper-devel-bounces@lists.sourceforge.net
</a><br>>> [mailto:<a href="mailto:pywrapper-devel-bounces@lists.sourceforge.net">pywrapper-devel-bounces@lists.sourceforge.net</a>] Im<br>>> Auftrag von John R. WIECZOREK<br>>> Gesendet: Montag, 17. Juli 2006 23:30
<br>>> An: Renato De Giovanni<br>>> Cc: <a href="mailto:pywrapper-devel@lists.sourceforge.net">pywrapper-devel@lists.sourceforge.net</a>; <a href="mailto:tdwg-tapir@lists.tdwg.org">tdwg-tapir@lists.tdwg.org</a>
<br>>> Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir:<br>>> capabilities<br>>><br>>> A little off topic, but it occurs to me that a great deal of<br>>> work is still ongoing with TAPIR, which suggests to me that
<br>>> it may be warranted to re-state my request for a simple<br>>> message type - a log request. This request would be the same<br>>> as a search request, except that the caller doesn't need a<br>>> response. Providers would use this type of request to log
<br>>> data usage if the data were retrieved from a cache elsewhere.<br>>> I remember talking about this in Berlin, at which time there<br>>> was supposed to be a feature freeze. Clearly we've gone<br>>> beyond that, so I'm requesting it again.
<br>>><br>>><br>>> On 7/17/06, Renato De Giovanni <<a href="mailto:renato@cria.org.br">renato@cria.org.br</a>> wrote:<br>>><br>>> Hi,<br>>><br>>> If I remember well, the "view" operation was re-included in the
<br>>> protocol just to handle query templates, especifically<br>>> for TapirLite<br>>> providers. So if someone wants to query a provider using some<br>>> external output model that should be dynamically
<br>>> parsed, then the<br>>> "search" operation must be used instead (using either<br>>> XML or simple<br>>> GET request). View operations are really bound to query<br>>> templates,
<br>>> and they are not allowed to specify "filter" or<br>>> "partial" parameters.<br>>> --<br>>> Renato<br>>><br>>> On 17 Jul 2006 at 21:26, "Döring, Markus" wrote:
<br>>><br>>> > I was just about to edit the schema and realizing<br>>> that output models<br>>> > are only specified for searches. but what about<br>>> views? they use<br>>> > query templates, yes. but only the ones listed in
<br>>> capabilities? we<br>>> > should have dynamic ones here as well I think. And<br>>> they link back to<br>>> > static/dynamic models.<br>>> ><br>>> > So should models maybe become a seperate section not tight to
<br>>> > search/view operations? I am going to modify the<br>>> schema nevertheless<br>>> > already to accomodate the changes below - ignoring<br>>> views for now.<br>>> >
<br>>> > Markus<br>>><br>>> _______________________________________________<br>>> tdwg-tapir mailing list<br>>> <a href="mailto:tdwg-tapir@lists.tdwg.org">tdwg-tapir@lists.tdwg.org
</a><br>>> <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-tapir">http://lists.tdwg.org/mailman/listinfo/tdwg-tapir</a><br>>> <<a href="http://lists.tdwg.org/mailman/listinfo/tdwg-tapir">http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
</a>><br>>><br>>><br>>><br>>><br>> _______________________________________________<br>> tdwg-tapir mailing list<br>> <a href="mailto:tdwg-tapir@lists.tdwg.org">tdwg-tapir@lists.tdwg.org
</a><br>> <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-tapir">http://lists.tdwg.org/mailman/listinfo/tdwg-tapir</a><br><br></blockquote></div><br>