Re: [PyWrapper-devel] view operation issues and others

[<wi...@go...>]

Renato, Javier,
I think we agree with most issues I raised. See comments below.
I copied the mail to the developer list cause Renato is right, this  
makes good documentation for others.
cheers,
Markus


>
> On 14.07.2006, at 03:22, Renato De Giovanni wrote:
>
> Hi Markus,
>
>> the pywrapper gets closer to the specs!
>
> Exciting stuff!
>
>> Im finishing the view implementation and got the following questions
>> - not sure if we tackled them yet:
>
> BTW, these are typical questions that only pop up during  
> implementation...
> And it's also the kind of conversation that we could make use of our
> mailing list, I think. Maybe other people could help defining these
> things.
>
> (oh, and Charles should also know about the final decisions.)
>
>> 1) Default response is with envelope turned off. What happens in case
>> of serious errors?
>>     - simple respond <Error>
>>     - turn on the envelope and response with response/error
>
> That's tricky. I kind of dislike the idea of turning on / off the  
> envelope
> at the provider side, because then clients should be prepared to  
> parse the
> response in different ways. On the other hand, "normal" clients  
> (like our
> portals) should always ask for enveloped responses I think.
> Envelopeless interactions would probably be left to more specific  
> clients,
> like GoogleEarth, GUID resolution, RSS clients, which would  
> probably crash
> anyway if there's some error, regardless we turn on the envelope or  
> return
> a different tag. Am I correct?
> Sooo... I don't know what would be the best solution. :-(
> Maybe turning on the envelope is the way to go.

Hard decision. It probably doesnt matter that much as you lined out  
above.
Lets turn on the envelope for now until we find better reasons/ 
solutions.



>
>> 2) we allow to use COUNT in views. But how does a count get returned
>> if there is no envelope?
>>     - turn on envelope
>>     - ignore it
>
> Similar problem... similar doubt...
> Ignoring doesn't seem a good approach in this case.

The same thing. We should maybe raise a warning that envelope=False &  
count=True do not go together.
Envelope will be turned on then!


>
>> And some general questions:
>> 3) What did we agree on to return if there were no matches for the
>> query?
>>     - empty search element?
>>     - some explicit notion of an empty recordset, eg. <NoMatches>
>
> I think the answer for this one is here:
> http://ww3.bgbm.org/protocolwiki/PreliminaryProtocolNotes
Oops. yes, we have dealt with this already. So just nothing instead  
of some explicit notion.


>
>> 4) capabilities. not sure about our terminology.could/should we renme
>> these:
>>     - predefinedOutputModels  -->  trustedOutputModels
>>     - mandatory (concepts)  -->  required
>
> I agree with Javi's comments.
> Not sure about which name could replace predefined. It must  
> constrast with
> "custom". Maybe "preconfigured", "known", "available"...
> Required sounds better than mandatory.

What about sharedOutputModels ?
And I also like required better than mandatory.
lets change both?




> --
> Renato
>
>
>