[Nautilus-list] Proposal for standard .oafinfo attributes

[Maciej Stachowiak <mjs eazel com>]

CC's because gnome-components-list continues to be kind of slow for
me.

Here is a proposal for some standard attributes for .oafinfo files; a
few proposed bonobo-wide ones, and some that might only be relevant to
nautilus, or nautilus components. Please comment. I would at the very
least like to add the "supported_mime_types" attribute mentioned below
to oafinfo files throughout Bonobo and Nautilus. It seems like a clear
win.

I especially want feedback on what other attributes could be useful
for activating (or browsing) objects, which of the attributes I have
specified might be ill-conceived, and on the open questions near the
bottom.


--------------------------------

Proposal for standard .oafinfo file attributes. Not all components
must specify all of these (although I recommend making at least
"repo_ids" and "description" mandatory), but if they are present they
ought to have these standardized meanings.

General

* "repo_ids" (stringv) - all the IDL interfaces this component
implements, including inherited interfaces. If Bonobo::Unknown is one
of the interfaces, this should include all interfaces that can be
query_interface()d for.  Fake interfaces like
IDL:BonoboControl/text-plain:1.0 should _not_ be included.

* "description" (string) - a free text description of the component,
much like the gnorba description field.

* "supported_mime_types" (stringv) - a list of mime types this
component understands as input. In addition to specific mime types, it
is possible to include supertypes (e.g. "image/*" or "text/*") or
"*/*" to indicate the component can display any mime type. Specifying
"*/*" is only necessary if "supported_uri_schemes" is not
specified. This only really makes sense if the component implements
one of the following interfaces: Bonobo::PersistStream,
Bonobo::ProgressiveDataSink, Nautilus::View.

* "editable" (boolean) - does this component allow editing of its
contents?

* "supported_uri_schemes" (stringv) - a list of protocols this
component knows how to handle. This only really makes sense if the
component implements one of the following interfaces:
Bonobo::PersistFile or Nautilus::View

  If "supported_uri_schemes" is specified but "supported_mime_types"
is not, it is assumed the component can handle any type of data that
might come via that protocol. Some schemes may not even have an
associated mime type for any given URI, for instance irc: or news:

  If "supported_mime_types" is specified but "supported_uri_schemes" is
not, the component is assumed to be able to handle all common URI
schemes (possible definition: anything gnome-vfs can handle).


Nautilus - General

* "nautilus_display_name" (string) - a suitable name for use as a view
as name ("View as <foo>") or a sidebar panel label name. This can (and
should!) be implemented by any Bonobo Embeddables or Controls that
might be used as Nautilus views.

Nautilus - Content Views

* "required_directory_content_mime_types" (stringv) - if the component
is to be activated on a URI with mime type special/directory, it is
only really applicable if the directory contains one of these mime
types. As before, supertypes like "audio/*" are allowed.

* "required_uri_tester" (string) - this specifies the OAFIID of a
component that implements the Nautilus::URITester interface (see
proposal below). If the criteria established by all the other
attributes are satisfied, an object with that OAFIID should be
activated and its is_applicable() method should be called on the URI
to test if it this component _really_, _really_ applies to the given
URI. This should be used as a last resort. 

The reason for the "required_uri_tester" attribute is as follows. In
Nautilus, we plan to have custom directory views that express
higher-level semantics about certain directories, but that depend
heavily on the directory contents. For example, there maybe "View as
Version Controlled Directory" or the like which depends on their being
a directory named "CVS/" in the appropriate directory. So in the most
general case, we need to run some code specific to the component to
make sure it is applicable to a given URI. Now, we could just activate
the component, require it to have the URITester interface, do the
test, and then destroy it to find out if it applies. But that might be
quite heavyweight. So intead we specify the OAFIID of a different
component, one which could be very lightweight (shlib or minimal exe
that does not pull gnome/gtk stuff) which does the test and nothing
else.


Nautilus - Meta Views:

* "recommended_uri_schemes" (string) - the URI schemes this meta view
is most recommended for. If "*" is included, this component is
recommended for all schemes. If omitted, it is not recommended for
any. This is only really applicable for components that implement
Nautilus::MetaView.


General open questions

* How does Bonobo::PersistStorage play into this?

* Is there another concept of a display name other than the
  description and the nautilus display name, perhaps for picking off a
  list?

* An "icon" attribute has been proposed for component browser/selector
  purposes.

* How to specify interesting info about applicable components when
  there is no relevant URI? For instance a regular dumb control. Maybe
  you only ever want to pick these off a list or activate a specific
  one by IID.

* Should "description" and "nautilus_display_name" be
  internationalized? If so, how? should there be other attributes with
  names like "description_${LANG}"?

Nautilus-specific open questions

* How do we get a nautilus display name for a component that does not
  specify one?

* Should the user level of a component be an attribute? That lets just
  any component author set the user level instead of centralizing it.

* What queries and sorting criteria should we use? Proposal to come
  later.

* How do user preferences relate to this? I am intentially
  sidestepping this issue for now.

==================


module Nautilus {
        interface URITester {
                boolean is_applicable (string uri);
        }
}