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

[John R. WIECZOREK]

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.

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.


On 7/18/06, Javier de la Torre <jatorre at mncn.csic.es> wrote:
>
> I am not sure about this,
>
> I still think that portals should be gathering this data and making
> it available for data providers...
>
> But in any case if you like it then I agree with MArkus that the best
> is to include another parameter in the operationRequestGroup.
>
> I havent checked but what happens if you do an extension there with
> an attribute that is implementation specific? A qualified attribute.
> Will this still validate against our schema? You were discussing
> about qualification of attributes before no?
>
> Javi.
>
> On 18/07/2006, at 10:41, Döring, Markus wrote:
>
> > 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>
> >>
> >>
> >>
> >>
> > _______________________________________________
> > tdwg-tapir mailing list
> > tdwg-tapir at lists.tdwg.org
> > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20060719/e493b965/attachment.html