[Desktop Bookmars] Adding link on the standards page

[Brad Hards]

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.

> > 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.
As I said - you've responded, not got concensus. 

> > 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.
IMHO, that is a cop-out. Either the spec says how it is done, or you have 
fundamental incompatibility between implementations. 

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

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

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

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

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

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

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

Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050517/369c5085/attachment.pgp