[Desktop Bookmars] Adding link on the standards page

[Emmanuele Bassi]

Hi Brad,

On Tue, 2005-05-17 at 20:25 +1000, Brad Hards wrote:
> On Tue, 17 May 2005 00:34 am, Emmanuele Bassi wrote:
> > He did not reply to the further revisions of the spec.
> He last replied less than a week ago. Take your time.

Heh, I'm used to high-traffic lists like the Gnome's
desktop-devel-list. :-)

> > The only issue, apart from the format, was the split-up of the desktop
> > bookmarks and the recent files.  I turnded down the "one file per
> > bookmark" option since parsing XML is not that bad (performance-wise)
> > these days, while loading multiple files would mean several I/O hits.
> As I said - you've responded, not got concensus. 

Nor I expected to have it at my first iteration. :-)

> > I admit I've taken as a rough model the recent files spec, and
> > concentrated more on the format section.  It should be pointed out that
> > each implementation should monitor the changes of the files defined by
> > the spec, and allow the notification if a change does occur.
> IMHO, that is a cop-out. Either the spec says how it is done, or you have 
> fundamental incompatibility between implementations. 

This is really very implementation specific, so I'll guess I'll just put
it under the "Implementation recommendations" section.

> > > What happens if there are two applications (as in your example) - which
> > > gets used if you invoke a bookmark?
> >
> > This is left to the implementor: the data stored in the "application"
> > tag is merely metadata, saying who registered that bookmark, when it
> > registered it, how many times it registered it and the preferred command
> > line used for loading the bookmark.
> That will cause conflicts between implementations. There isn't any point in a 
> specification that doesn't have defined semantics.

I don't see why it would cause conflicts.

We define the metadata in the spec, and we guarantee that said metadata
must be present.

Which application should be used, as I said, is left to the implementor:
the panel might want to use the default MIME handler, or the latest used
application, or the most used application; an application might want to
use another instance of itself.

That is why we store such metadata as the MIME type, the applications
that have registered the bookmark and how many times they have done it.

> > As a rule of thumb, the bookmark should be opened using either:
> >
> > 	1. the default handler for the MIME type
> > 	2. one of the applications that has registered it (using the given
> > command line)
> >
> > The latter should be preferred (using startup notification, if present),
> > and the former should be the fallback.
> That needs to be in the spec.

I'll add it in the "Implementation Recommendations".

> > >  What if an application is added or upgraded?
> >
> > I don't understand this point.  If an application has been added, then
> > it has no registered bookmarks - unless it's the new default MIME
> > handler, it won't be associated to a bookmark.  As well as if an
> > application has been upgraded - unless it changed its command-line.
> This partly relates to how symbolic names are used, and partly to preference 
> systems. If the user changes the preferred mailer, then what happens to any 
> bookmarks that are associated with a symbolic name, or with the old mailer?

By "symbolic name" I intended "an application's name which is not the
binary filename", e.g. Nautilus could use "nautilus" or "Nautilus"; The
GIMP could use "gimp" or "Gimp" or "GIMP"; etc.  I understand that this
could be misunderstood, so I'll just use "application's name", and let
applications use their preferred name.

As for "preferred applications", that's why I added groups.  When a user
changes its preferred mailer, as long as the old AND the new MUA
register bookmarks in the "Mail" group, their bookmarks will be visible
to each other.  When the user launches a bookmark using its new mail
agent, the bookmark will be registered for that application too, and the
bookmark will be associated to that program.

+++

Just to make myself clear, suppose you have an application A registering
a bookmark for a URI U at a time T; suppose that this application has a
name of "A", a command line of "A <uri>" and its bookmarks belong to the
"GroupA" group; suppose also that this bookmark was never before
registered (even if this assumption is not necessary but for
simplicity's sake):

	A	------> register bookmark using U, using my metadata

The bookmark implementation will, then

	bookmarks <---- add a new bookmark with URI "U"; register
			a new application, with name set to "A",
			timestamp set to "now", exec set to "A %u",
			and count to "1"; also, add a group named
			"GroupA".

The user now launches application B (with a metadata tuple set to ("B",
"B <file>").  This application does the same job of application A, and
so it will check bookmarks belonging to "GroupA", in addition to the
bookmarks which it may have directely registered.

When the user will access the bookmark with URI U, displayed by
application B, application B will automatically register it:

	B	------>	register bookmark using U

	bookmarks ----> find the bookmark with URI "U"; register
			a new application, with name set to "B",
			timestamp set to "now", exec set to "B %f",
			and count to "1".

A this point, the bookmark will have a total registrations count of 2,
will have been registered by applications A and B, and thus will appear
inside both application A and application B; it will also appear to
every application checking bookmarks belonging to "GroupA".

Suppose, now, that we have a generic lancher, such as an applet of the
Gnome Panel.  It will be a viewer only, monitoring the bookmarks file
for changes, and will check the bookmarks of a specific group, say
"GroupA".  After the registration done by applications A and B, it will
see that:

	1. there is a bookmark there that has been launched twice;
	2. this bookmark has two registered applications, A and B;
	3. the latest application that has registered it is B;

The user has previsously configured the applet in order to launch the
most recently used application that has registered a bookmark
(alternatively: the applet shows the user a disambiguation dialog,
letting her/him choose).  The user launches the bookmark, and the applet
launches the B using its command line.  Since the applet is only a
viewer, it will not write the bookmarks file; but application B will,
and it will register itself - again.

The bookmark will now have a total registration count of 3, and
application B registration cound will be 2.

+++

Hope that this clarifies a bit more some points of the spec.  I'll
review the text, and make this a use case example.

> > If the status of the object pointed by the URI used for a bookmark
> > changes, the implementor should know how to handle the case.
> >
> > We are defining a data storage format, not what to do with the stored
> > data.
> This makes the whole spec pointless, except as the basis for another spec that 
> defines the semantics. If the behaviour is implementation defined, then 
> you're wasting your time.

I'm defining the semantics of a desktop-related bookmark as a set of
metadata needed for desktop applications.

Defining what an application should do when creating and accessing said
metadata should be the scope of this spec; defining what an application
should or should not do with that metadata pertains to the applications
space.

> > >  What is the purpose of "count", as in what is the purpose of knowing
> > > about how many duplicate registrations of a bookmark have been made?
> >
> > This was a request done on the Gnome mailing lists and wiki: we could
> > track the most used applications using the count attribute, apart from
> > the most recently used ones (using the timestamp attribute).  It is
> > useful in the case of the recently used objects, but I can see it useful
> > also for desktop bookmarks.
> So is re-registration mandatory or not?

It is always mandatory when creating a bookmark, and when updating it
(see above).

> > > 7. The idea of Groups is pretty broken without a defined list of them.
> >
> > General purpose groups, like the ones defined inside the Desktop Item
> > spec could be used; but I'd like applications to be able to define their
> > own groups, like "Gimp Palettes" for instance.
> The spec uses the Mail example.  Why not Mailer or Email  or MAIL? If you 
> don't define standard groups, then everything is application specific, and 
> the spec might as well use a different file for every app. 

In the new spec revision I've added the reference to the Menu Entry
specification.  I'll just copy the categories, and will keep them in
sync, so that the same categories used for a menu entry will be usable
by the bookmarks.

Kind regards,
 Emmanuele.

-- 
Emmanuele Bassi <ebassi at gmail.com>
Web site: http://log.emmanuelebassi.net