Re: summary of the previous thread on oaf IIDs (as I remember it)

[Maciej Stachowiak <mjs eazel com>]

First off, I'd like to thank Mathieu for his earlier summary. I'd like
to make one minor correction, which is that the way UUIDs are
generated, they actually 100% guarantee uniqueness, not just
probabilitically. I'll dig out the RFC in a bit and post a link here.

I'm sorry I haven't followed this converasation more closely, but I
was unsubbed from g-c-l and only re-subbed today, so I missed many of
the posts that were not CC'd to me.

> 
> I'd suggest the following:
> 
>         - we keep the current UUID convention
> 
>         - we allow people to leave away the uuid part in all
>           OAF queries.
> 
> So, for instance, internally the thingie will still have
> 
>         OAFIID:eog_image:20fecf27-a66e-4e0d-bb87-d519a5693ba1
> 
> but you can ask OAF for just `OAFIID:eog_image' (in this case we'd need to
> namespace this to become `OAFIID:gnome_eog_image') and it'll work.
> 
> How does this sound ?

I can think of a real easy way to implement this, which is to add a
starts_with operator to OAF. Then you can do a query like:

"iid.starts_with('OAFIID:gnome_eog_image:')"

I'd like to keep `activate_from_id()' requiring the full IID though,
since it really needs to be passed a true unique identifier, since it
has no way to resolve conflicts. `oaf_query()' and `oaf_activate()'
both have explicit sorting order passed to them; and `oaf_query()'
returns info on all the matching objects (sorted according to the
specified criteria) while `oaf_activate()' activates the object that
sorts the highest.

So using _query or _activate instead of _activate_from_id will
maintain the clarity that you are not using a truly unique ID, but
only a shortcut name.

Does this sound reasonable?

The one problem I have with this proposal is that people may be
encouraged to use the starts_with form, which is kind of bad style. I
would still prefer that people use the full IID, or, better yet, as
Mathieu so eloquently argued, not hardcode IIDs at all, but rather do
a query for a component that has the capabilities you need (this does
not have to be only interfaces but can also be things like supported
mime types, URI schemes handled, etc).

As Mathieu pointed out, you can replace any of the Nautilus views you
want, including the icon and list views. In current Evolution, you can
also add or replace Evolution shell components, which also makes for a
very powerful, extensible groupware platform (Mathieu got this wrong,
I hear someone has corrected him, but I wanted to underscore this
point). I also applaud the Evolution hackers for using the gnome-vfs
mechanism for mime mappings, which lets users customize the view
components they use for attachments. By having these query mechanisms,
we're able to make Nautilus and Evolution a lot more powerful and
extensible than the Microsoft equivalents, and I hope this paves the
way for the next generation of GNOME apps.

I do recognize that there are times you do want to hardcode IIDs - for
instance, it would be silly for the EOG program to query for an
arbitrary component to handle EOG images.

So I agree to make this case easier, but I still think it's better to
use the full IID when you need it.


Regards, 

Maciej