libxdg

DAV dav.daemon at gmail.com
Tue Jul 17 08:32:51 PDT 2012


Hi, David!

> > > > Do you think this could be done? Or am I overlooking some
difficulty here?
> > >
> > > It could easily be done by adding one more function which will group
the
> > > results from
> > > different groups ("Default Associations", "Added associations", etc).
> > > By the way, this functionality is implemented in example in online
> > > documentation.
> >
> > I'm not asking for more functions, but for a different layout in the
on-disk
> > cache :-)
> >
> > But yes, this goes together. The most common use case for this library
should
> > require a single function (plus iteration loop) rather than three (plus
> > iteration loop), and the on-disk cache should be optimized for this use
case.
> >
> > If the user-preferences-handling code needs to explicitely access
"added" and
> > "removed" lists, it can just use the mimeapps.list files, as it does
already.
> > So if you want to keep this API in the library, it could just read
these files
> > directly. Or don't provide it.
> > But the goal of the on-disk cache is really to pre-process the data in
order
> > to make the "which app(s) handle this mimetype" lookup as fast as
possible,
> > and as simple as possible for developers.
>
> Yes, it definitely is. I will merge trees representing associations of
mime types with
> "added", "default", "all other" and "removed" lists in the next release
(within couple
> weeks).

Done. I have removed AVL tree responsible for groups in ".list" files.
Also, algorithm of
parsing of ".list" files is updated: now it forms an AVL tree ready to
lookup a single list
of applications able to handle given mime type. Of course, format of the
binary cache
became a bit simpler because it lost one AVL tree.

repo: https://github.com/vilkov/libxdg
tag: https://github.com/vilkov/libxdg/zipball/rc-0.2.1
doc: http://vilkov.github.com/libxdg

--------------------------------
Best regards, Dmitriy.



2012/7/3 DAV <dav.daemon at gmail.com>

> > > > Do you think this could be done? Or am I overlooking some difficulty
> here?
> > >
> > > It could easily be done by adding one more function which will group
> the
> > > results from
> > > different groups ("Default Associations", "Added associations", etc).
> > > By the way, this functionality is implemented in example in online
> > > documentation.
> >
> > I'm not asking for more functions, but for a different layout in the
> on-disk
> > cache :-)
> >
> > But yes, this goes together. The most common use case for this library
> should
> > require a single function (plus iteration loop) rather than three (plus
> > iteration loop), and the on-disk cache should be optimized for this use
> case.
> >
> > If the user-preferences-handling code needs to explicitely access
> "added" and
> > "removed" lists, it can just use the mimeapps.list files, as it does
> already.
> > So if you want to keep this API in the library, it could just read
> these files
> > directly. Or don't provide it.
> > But the goal of the on-disk cache is really to pre-process the data in
> order
> > to make the "which app(s) handle this mimetype" lookup as fast as
> possible,
> > and as simple as possible for developers.
>
> Yes, it definitely is. I will merge trees representing associations of
> mime types with
> "added", "default", "all other" and "removed" lists in the next release
> (within couple
> weeks).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20120717/949e81c3/attachment.html>


More information about the xdg mailing list