[Desktop Bookmars] Adding link on the standards page

[Emmanuele Bassi]

Hi,

On Mon, 2005-05-16 at 20:19 +1000, Brad Hards wrote:
> On Mon, 16 May 2005 19:36 pm, Emmanuele Bassi wrote:
> > Since my draft has been reviewed, and it seems that no one opposed the
> > design, may I add an external link for it to the drafts section of the
> > fd.o Standards page?

> I don't know what the rules are for adding links and I didn't review the spec 
> in detail, however after a review of the email chain, I don't think you 
> addressed all of the concerns raised, especially not those by Daniel 
> Veillard. You responded to his email,  which is not exactly the same as 
> getting concensus.

He did not reply to the further revisions of the spec.

The specific issue was Daniel Veillard was referring was about the
(eventual) shortcomings of XBEL.  I moved my custom markup to a set of
tags inside an XBEL metadata section - and I've pointed out that having
to define custom metadata did require the same amount of time as
defining a new standard.

Having decided to follow the "custom metadata for XBEL" route for the
following revisions, I thought that the question was settled; but, as
I've already said, I'm open to suggestions: that's why I created this
draft in the first place, and sent it here for review. :-)

> You might want to review what everyone wrote, and whether you have addressed 
> the issues.

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.

> My suggestions:

> 1. The Storage Format (section 2) is primarily an example. I'd suggest a 
> definition first, and an explanation using an example if required. 
> 2. You should add a normative reference to the XBEL spec
> 3. You should add a normative reference to wherever XDG_DATA_DIRS comes from

I have fixed these issues.

> 4. You claim that the spec aims to "Allow for notification of changes in the 
> list". However there is nothing in the spec that specifically provides for 
> notifications - suggesting use of FAM or polling the whole file not 
> withstanding.

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.

> 5. I'm not sure what the <bookmark:application> bit is going to be used for. 

Bookmarks are top-level objects, which could be "registered" by more
than one application.  Each "application" tag should contain the
application that has registered that bookmark, in order to allow
multiple applications to share the same bookmarks, and to avoid
replication.

> 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.

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.

>   What if the file association is changed in some system-central location?

If no default handler for the MIME type has been defined, either any of
the applications that has registered that bookmark should be invoked
(asking the user first) or the implementor could decide to fail.

>  What if the application is deleted from the system?

Then the implementor might fail, or it might decide to use the default
MIME handler.

>  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.

>  What if an application deletes the file?

The status of the object pointed by the bookmarks should be checked, but
dangling bookmarks should be allowed; think, for instance, of a bookmark
to a website: it could temporarily be offline, returning a 404 error;
still, I don't want the bookmark to be removed unless I know for sure
that it indeed points to nothing.

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.

>  When can an app use a symbolic name instead of the binary name?

It is left to the application to choose a name: we guarantee that, if a
bookmark has already a registered application under that name, the
timestamp and the count will be updated.

>  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.

> 6. There are at least two typos. Finding them is left as exercise :-)

Sorry for the typos: english is not my first language.  I also suspect
that I used some horrible phrasing, here and there. :-)

> 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.

Kind regards,
 Emmanuele.

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