Re: dot-oaf style questions

["Dirk-Jan C. Binnema" <bulkmeel yahoo co uk>]

Hi Darin,

Op wo 28-11-2001, om 17:42 schreef Darin Adler:
> on 11/21/01 12:08 PM, Dirk-Jan C. Binnema at bulkmeel yahoo co uk wrote:
> 
> > - shouldn't oaf files use the <?xml version="1.0"> to be well-formed?
> > does anybody care?
> 
> Sure. They should. But it's not a disaster that they don't.
> 
> > - <!-- comments --> in .oaf files are not allowed, although they would
> > be quite useful; any work being done to add support for comments?
> 
> They should be allowed. What gives you the impression that they are not?

Well, the example from my tutorial, where I use a regular
bonobo_object_activate.

mindcrime:% ./bonobo-sample-moody-client
Q: hey good mood component, how are you?
A: Hi, how are you!
Q: hey bad mood component, how are you?
A: Grmpff... stop bothering me!

mindcrime:% sudo vi /usr/share/oaf/Bonobo_Sample_MoodyComponent.oaf

[adding <!--comment --> at top of file]

mindcrime:% ./bonobo-sample-moody-client

** ERROR **: failed to create a moody component

aborting...

...and after removing it works again. Note, I am using Bonobo1 here.
When you append stuff *after* the final </oaf_info>, it does work...
Also, it doesn't seem to matter if it's a comment or just some
newlines...

I see similar behaviour in Nautilus, when I prepend a couple of newlines
to "/usr/share/oaf/Nautilus_View_tree.oaf", which will break the tree
most of the time (but now always?!). 


I'll check the code and see if I can figure it out...

> Since we just use libxml to parse the files, I can't see how we could
> disallow comments.

Hmmm...

> > - in my /usr/share/oaf i see many oaf files that have
> > "IDL:Bonobo/Unknown:1.0" as one of their repo_ids; that doesn't seem
> > correct; either the corresponding components *do* expose Bonobo/Unknown
> > (which seems rather pointless), or else they don't in which case the
> > .oaf files are wrong. Note that exposing e.g "Bonobo/Control" does *not*
> > mean you're automagically exposing Bonobo/Unknown (although of course
> > Bonobo/Control derives from Bonobo/Unknown.
> 
> In practice, it currently doesn't matter if these lists of repo_ids aren't
> exactly right, which is what creates the problem. The only time the repo_ids
> matter is when doing bonobo-activation queries, such as the ones that
> Nautilus uses to find views. So the people creating the files can get them
> wrong as long as they are "close enough". If we want people to get them
> right, we probably need some way to check them. Asking people to get them
> right with no way to test is like asking someone to write a program and
> debug it without ever being able to run it.

Yes. We could write a Perl script which examines the OAF files,
activates Bonobo components, and uses query_interface to check if the
supported interfaces match the repo_ids in the .oaf.

However, is that a good criterion for "oaf-correctness"? (see below)

> You seem pretty sure of the semantics here. But I'm not. Exposing
> Bonobo/Control, which derives from Bonobo/Unknown, does seem like it exposes
> Bonobo/Unknown. But this is all beside the point for the current uses of
> repo_ids anyway, so it's probably not worth debating.

Thinking about it again, I'm not so sure either ;-)

In principle multiple interfaces and inheritance are two separate
concerns, so ideally I think you shouldn't mix them.

However, the problem with this is that if you have a component
implementing the MyFunkyControl interface (which derives from
Bonobo::Control), you *do* want it to match a query for Bonobo::Control,
since it *is* a Bonobo::Control, and there's no way for OAF to find out
otherwise then adding their repo_ids to the .oaf file.

So should we then aim for 1:1 correspondence between the oaf-listed and
component-exposed interfaces then? (ie. dot-oaf and query_interface tell
the same story)

Well, that would be nice, if not for the fact OAF doesn't know about
inheritance... so, for example, for the correspondence to hold, we would
have to expose a [fake] Bonobo::Control interface for any
Bonobo::Control subclass-implementing component, because we're forced
(see above) to add Bonobo::Control to it's repo_ids in the .oaf-file.

[One way to prevent these fake implementations would be to make
query_interface inheritance-aware.]

I guess the long-term nicer solutions would be to make OAF/BAF
inheritance-aware. That way only the leaf-interfaces have to be listed,
and OAF can still do right thing with matching, upcasting etc. This
would also make the dot-oaf/component correspondence verifiable again.

In the meantime, the current setup seems to work quite well; still, OAF
hasn't really been used as a dev lib very much outside the GNOME
innercircle...

--Dirk-Jan.

-- 
-----------------------------------------------------------
Dirk-Jan Binnema, djcb djcbsoftware nl, www.djcbsoftware.nl
-----------------------------------------------------------
pgp fp:  BB49 41D7 053D E5F1 F333  586E C530 CBC3 4352 A39F
-----------------------------------------------------------