Re: [bug-GIFT] Inconsistency in MRML? - perhaps there should be an MRML warning message?

[Wolfgang Mueller]

Hi, David,

I guess you don't mind that I put the answer of your message to the list, as 
I think it's important, and I assume you just forgot to do a reply-all 
instead of a reply.

On Thursday 27 September 2001 22:16, David Squire wrote:
(snip)
> > In fact the exception business was cancelled, when I realized
> > that the gcc
> > 2.81 did EITHER support exceptions, OR runtime type
> > identification (RTTI),
>
> Perhaps I have misunderstood, but I certainly tracked down where in the
> code the error message was being generated, and it seemed like an exception
> to me.
(snip)

Nono, you're not getting anything wrong. There ARE exceptions in the code, 
mainly to find out when it WOULD work. Exceptions and RTTI work nicely (at 
least for me, and only as far as I know) since g++ 2.95 . However, these 
exceptions are not treated in the thorough fashion they deserve (this is what 
I mean with "having quit the exception business"), and especially 
they get caught in the same file in which they are thrown instead of the 
right place (at least in one case, and I remember having left things in this 
state).

> Question: is there any good reason why an algorithm which is requested in a
> query should not automatically be configured if it has not already been?

You will laugh, but two years ago I started out this way, and then I quit 
because of said exception trouble. But yes, I think that it is good to 
request at least a bit of rigor from the client. I find it's better to give 
the client some message

"Hya, you did not configure correctly"

than giving some results, where the user never finds out if it was what he 
configured.

> > What I will write "soon"  is orderly exception handling which should also
> > avoid the annoying crashes we get in certain situations. When
> > this exception
> > business is done, calling for an unconfigured algorithm will give you an
> > error (mrml error message, which the client can show).
>
> Regarding the "collection", "collection-id" thing, perhaps the server
> should return some sort of mrml warning message when it receives elements
> it does not recognize. This would not violate the graceful degradation
> principle, since the client could ignore them, but it would help developers
> to find out what is going on.

I do think it violates something: Imagine somebody sending region queries 
with plenty of tags, causing lots of error messages on top of the normal 
stuff... I would regard it as useful to be able to send something like a 

cui-debug-level="1"

attribute with the top-level mrml tag. Than you can program a reaction to the 
tag like <!-- unknown tag <sumpn> contents of this tag ignored -->

To summarise the reactions I will take to our series of mails is that I am 
looking into the exception business NOW for some parts of the evening, and I 
will see in a more detailed fashion how things can be moved in the right 
direction. The goal of this is to make the gift more stable. As I see things, 
instability is mainly in libMRML, so changes there will benefit all query 
engines. 

After that we can see, how we can include such a debug-level tag into the 
gift. We would also have to create something flexible for how to let the gift 
know what's unknown... See what I mean? All parts have to know what they 
know. I guess that there will be some cui-known-tag-list in the 
configuration, and a special visitor which generates warnings?

Let's see. 

Cheers,
Wolfgang

-- 
Dr. Wolfgang M&uuml;ller, assistant == teaching assistant
Personal page: http://cui.unige.ch/~vision/members/WolfgangMueller.html 
Maintainer, GNU Image Finding Tool (http://www.gnu.org/software/gift)