pywrapper-devel

Re: [PyWrapper-devel] tapir get requests & views

[<m.d...@BG...>]

So you are suggesting that the formerly global parameter "envelope" is =
only allowed in searches or views based on search templates but not on =
inventories? Thats a change too:

http://ww3.bgbm.org/protocolwiki/GetInvokedOperations

We really need to update this page to have a definite reference. Views =
are missing entirely.

I was collecting some changes on the wiki so charles doesnt forget to =
include them in the specs. its really not finished and already outdated, =
but we need it documented somewhere. Please feel free to edit it =
continously!

http://ww3.bgbm.org/protocolwiki/ImplementationAndDocumentationChanges



-- Markus
 =20

> -----Urspr=FCngliche Nachricht-----
> Von: pyw...@li...=20
> [mailto:pyw...@li...] Im=20
> Auftrag von Javier de la Torre
> Gesendet: Mittwoch, 19. Juli 2006 10:30
> An: Markus D=F6ring
> Cc: Renato de Giovanni;=20
> pyw...@li...; D=F6ring, Markus
> Betreff: Re: [PyWrapper-devel] tapir get requests & views
>=20
> Hi Markus,
>=20
> I leave some questions open.
>=20
> > - is the envelope turned off or on when non view requests=20
> are called=20
> > via GET? I thought its turned off then. Am I right?
>=20
> Uff... I would expect it to be turn on, this is the TAPIR=20
> protocol and therefore we should use our envelope unless the=20
> user says no.
>=20
> > - inventories without envelope need some embracing root=20
> element above=20
> > the <record> elements. So should we answer with <tapir:inventory> ?
> This is because we didnt think on inventories without=20
> envelope. If we have to invent an embracing element then I=20
> prefer to have the proper envelope.
> Inventories are a very TAPIR thing. I have the impression=20
> that what you actually want is to have inventories as an=20
> specific search with a select distinct operator. What is=20
> actually fine for me, but I would not make such change now.
>=20
> > - If so, shouldnt we do the same for the other operations (with=20
> > exception of views maybe - well, actually an inventory view has the=20
> > same problem!). If we would do so, the summary element for=20
> paging is=20
> > there as well and we would not need to turn on the entire=20
> envelope for=20
> > counts.
>=20
> Does it matter to have a half envelope or a full envelope? I=20
> think I rather stay with an envelope.
>=20
> > - if not, what about ping?
> pong.
>=20
>=20
>=20
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT Join=20
> SourceForge.net's Techsay panel and you'll get the chance to=20
> share your opinions on IT & business topics through brief=20
> surveys -- and earn cash=20
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
&CID=3DDEVDEV
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>=20

Re: [PyWrapper-devel] tapir get requests & views

[Renato De G. <re...@cr...>]

Hi,

> Im checking the GET invoked operations now and I cant remember the 
> reason why we introduced another view request. We should provide  
> Charles some arguments why it exists and why we didnt just include 
> template as a parameter in inventories and searches. What was wrong 
> about that?

As I said, the only reason for the view operation was to accommodate 
TAPIRLite providers. Apparently it was the easiest way to do that. 
Remeber their requirements:

* No need to parse XML requests (only GET requests with simple 
key/value parameters)
* No need to parse filters.
* No need to implement "partial".
* All queries based on templates.

There could be other ways to allow the existence of TAPIRLite without 
having the view operation, such as including many new attributes in 
the search operation capabilities, but it would easily get confusing 
and contradictory, I think.

Searches and inventories can make use of templates already, can't 
they? (at least in XML requests, but I don't see why not via GET 
requests as well).

> - is the envelope turned off or on when non view requests are called
> via GET? I thought its turned off then. Am I right?

If this is not documented/defined somewhere I would suggest to turn 
on the envelope by default for all non view requests.

> - inventories without envelope need some embracing root element
> above  
> the <record> elements. So should we answer with <tapir:inventory>
> ?

I understood that turning off envelopes just meant removing header 
and diagnostics. The root element would still be <response>.

> - If so, shouldnt we do the same for the other operations (with  
> exception of views maybe - well, actually an inventory view has the 
> same problem!). If we would do so, the summary element for paging is
> there as well and we would not need to turn on the entire envelope 
> for counts.
> - if not, what about ping?

Same answer above.
 
> Looks like I am discovering ever more little questions.
> Stay tuned.

No worries, let's kill them all!
--
Renato

Re: [PyWrapper-devel] tapir get requests & views

[<m.d...@BG...>]

Hello,
turning off the envelope meant for me only to return the pure content - =
for example an ABCD record. It was mainly inspired to have a "view" on a =
single ID to get only the XML describing the object. Or to get pure RSS =
or KML for several objects.=20

If its only to turn off the header and diagnostics I think we wouldnt =
need it, a client would have to deal with TAPIR anyway.


-- Markus
 =20

> -----Urspr=FCngliche Nachricht-----
> Von: pyw...@li...=20
> [mailto:pyw...@li...] Im=20
> Auftrag von Renato De Giovanni
> Gesendet: Mittwoch, 19. Juli 2006 21:53
> An: pyw...@li...
> Betreff: Re: [PyWrapper-devel] tapir get requests & views
>=20
> Hi,
>=20
> > Im checking the GET invoked operations now and I cant remember the=20
> > reason why we introduced another view request. We should provide=20
> > Charles some arguments why it exists and why we didnt just include=20
> > template as a parameter in inventories and searches. What was wrong=20
> > about that?
>=20
> As I said, the only reason for the view operation was to=20
> accommodate TAPIRLite providers. Apparently it was the=20
> easiest way to do that.=20
> Remeber their requirements:
>=20
> * No need to parse XML requests (only GET requests with=20
> simple key/value parameters)
> * No need to parse filters.
> * No need to implement "partial".
> * All queries based on templates.
>=20
> There could be other ways to allow the existence of TAPIRLite=20
> without having the view operation, such as including many new=20
> attributes in the search operation capabilities, but it would=20
> easily get confusing and contradictory, I think.
>=20
> Searches and inventories can make use of templates already,=20
> can't they? (at least in XML requests, but I don't see why=20
> not via GET requests as well).
>=20
> > - is the envelope turned off or on when non view requests=20
> are called=20
> > via GET? I thought its turned off then. Am I right?
>=20
> If this is not documented/defined somewhere I would suggest=20
> to turn on the envelope by default for all non view requests.
>=20
> > - inventories without envelope need some embracing root=20
> element above=20
> > the <record> elements. So should we answer with <tapir:inventory> ?
>=20
> I understood that turning off envelopes just meant removing=20
> header and diagnostics. The root element would still be <response>.
>=20
> > - If so, shouldnt we do the same for the other operations (with=20
> > exception of views maybe - well, actually an inventory view has the=20
> > same problem!). If we would do so, the summary element for=20
> paging is=20
> > there as well and we would not need to turn on the entire=20
> envelope for=20
> > counts.
> > - if not, what about ping?
>=20
> Same answer above.
> =20
> > Looks like I am discovering ever more little questions.
> > Stay tuned.
>=20
> No worries, let's kill them all!
> --
> Renato
>=20
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT Join=20
> SourceForge.net's Techsay panel and you'll get the chance to=20
> share your opinions on IT & business topics through brief=20
> surveys -- and earn cash=20
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
&CID=3DDEVDEV
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>=20

Re: [PyWrapper-devel] tapir get requests & views

[Renato De G. <re...@cr...>]

Hi Markus,

Sorry, you're right about this. I'm talking with Javier now, and our
suggestion is:

* envelopeless responses only allowed for search operations.
* the content will be what goes inside <search>, so it will exclude
<summary>. I think we can assume that the client knows what he/she is
doing.
If paging is necessary (which is a TAPIR feature) then envelope needs to
turned on.

Is that OK?

Regards,
--
Renato

> Hello,
> turning off the envelope meant for me only to return the pure content -
> for example an ABCD record. It was mainly inspired to have a "view" on a
> single ID to get only the XML describing the object. Or to get pure RSS or
> KML for several objects.
>
> If its only to turn off the header and diagnostics I think we wouldnt need
> it, a client would have to deal with TAPIR anyway.
>
>
> -- Markus

Re: [PyWrapper-devel] tapir get requests & views

[<m.d...@BG...>]

Yes, I think I like it like that.=20

So the last one to be sure. An envelopeless counting search will ignore =
the count or turn on the envelope?

coffee and Ill be back...

-- Markus
 =20

> -----Urspr=FCngliche Nachricht-----
> Von: pyw...@li...=20
> [mailto:pyw...@li...] Im=20
> Auftrag von Renato De Giovanni
> Gesendet: Dienstag, 25. Juli 2006 13:42
> An: PyWrapper Developers mailing list
> Betreff: Re: [PyWrapper-devel] tapir get requests & views
>=20
> Hi Markus,
>=20
> Sorry, you're right about this. I'm talking with Javier now,=20
> and our suggestion is:
>=20
> * envelopeless responses only allowed for search operations.
> * the content will be what goes inside <search>, so it will=20
> exclude <summary>. I think we can assume that the client=20
> knows what he/she is doing.
> If paging is necessary (which is a TAPIR feature) then=20
> envelope needs to turned on.
>=20
> Is that OK?
>=20
> Regards,
> --
> Renato
>=20
> > Hello,
> > turning off the envelope meant for me only to return the=20
> pure content=20
> > - for example an ABCD record. It was mainly inspired to=20
> have a "view"=20
> > on a single ID to get only the XML describing the object. Or to get=20
> > pure RSS or KML for several objects.
> >
> > If its only to turn off the header and diagnostics I think=20
> we wouldnt=20
> > need it, a client would have to deal with TAPIR anyway.
> >
> >
> > -- Markus
>=20
>=20
>=20
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT Join=20
> SourceForge.net's Techsay panel and you'll get the chance to=20
> share your opinions on IT & business topics through brief=20
> surveys -- and earn cash=20
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
&CID=3DDEVDEV
> _______________________________________________
> PyWrapper-devel mailing list
> PyW...@li...
> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
>=20