Re: Querying oaf of the interfaces a component implements ?
- From: "Diego Sevilla Ruiz (dsevilla um es)" <dsevilla ditec um es>
- To: Maciej Stachowiak <mjs eazel com>, sopwith redhat com, gnome-components-list gnome org
- Subject: Re: Querying oaf of the interfaces a component implements ?
- Date: Tue, 17 Oct 2000 13:23:13 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Maciej Stachowiak wrote:
> Elliot Lee <sopwith redhat com> writes:
>
> > On 15 Oct 2000, Maciej Stachowiak wrote:
> >
> > > Yes. Do a query for "iid = 'OAFIID:foo:bar'" and you will get back an
> > > OAF_ServerInfoList, which is an array of OAF_ServerInfo. OAF has some
> > > calls to get at the values in a ServerInfo struct. Of course, the
> > > accuracy of this information depends on the component author filling
> > > out the repo_ids attribute accurately and including all the interfaces
> > > the component implements. I've seen cases out there where this is not
> > > done (for example the oafinfo files for a number of Evolution shell
> > > components are missing at least "IDL:Bonobo/Unknown:1.0").
> >
> > The theory behind this is that repo_ids is not an exhaustive list, but a
> > list of "interesting" interfaces that one would care to activate by. There
> > would not be any useful purpose served by activating by the
> > IDL:Bonobo/Unknown:1.0 repo ID, so it is left out of the list.
> >
>
> I disagree, this list should be exhaustive.
Yes, I think this also.
First intention of .oafinfo files are to list activation-specific
interfaces, but, possibly in the future, this can also be an information
repository for components. The IR does not know of different interfaces a
component supports, and the information of each component's interfaces must be
obtained by the QueryInterface operation.
Anyway, in order for an application to select the "most adequate" component
for its needs (through the OAF query language), the list in oafinfo should be
as exhaustive as possible.
> There are CORBA servers
> out there with associated oafinfo files that don't inherit from
> Bonobo::Unknown at all, and I can think of various kinds of Bonobo
> object browsers that would want to leave those out, since they can't
> be memory managed in a generic way.
I can't imagine a server/component in this way. Could you put an example of
such a component? I think that IUnknown interface is a special one, as it
should be included in all components, so it must be suposed to be.
> There's really no harm to being
> exhaustive, and I recommend that people make their lists complete.
>
As I said, I agree.
>
> - Maciej
>
Regards.
diego.
--
Diego Sevilla Ruiz -- http://ditec.um.es/~dsevilla/ -- dsevilla um es
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN). - Tel. +34-968-367570
PGP: http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xC9B964B7
\huge d\em\kern-.36em\lower-.2ex\hbox{\small sevilla}\kern- 1em um es
perl -e'$_="\x4\ FLe\x2&B";for(/../g){print unpack("b*",$_),"\n"}'|tr 01 " #"
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: V7t8tCtjTS82/7qXmZILmAbbJwvl+de1
iQA/AwUBOew2rNoq0AfJuWS3EQI5AwCeO2BCskrtAImMjFhDobEoQz+YZp0AoIgW
FJxdlpT2SdWQ2j/9fvPJbMVR
=duF2
-----END PGP SIGNATURE-----
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]