Re: [Lxde-list] [Pcmanfm-develop] concerning a compact and reliable key-value database: (rw)cdb

[PCMan <pcm...@gm...>]

On Thu, Nov 7, 2013 at 11:59 PM, Andrej N. Gritsenko <an...@re...>wrote:

>     Hello!
>
> u-...@ae... has written on Thursday,  7 November, at 14:23:
> >Having in mind the goal of keeping Lxde small I would suggest
> >considering a compact one without any redundant features.
>
>     Well, we've completely lost point of discussion I've started. It is
> not about implementation of data storage. It is about where to store data
> about directory-related settings of pcmanfm. So far there are 3 variants:
>
> 1) the file '.directory' in the target folder;
> 2) the extended FS attributes of target folder;
> 3) the centralized storage somewhere inside homedir.
>
> The centralized storage has few drawbacks:
>
> 1) it is application dependent - you cannot use setting made in pcmanfm
>     even by pcmanfm-qt, no tell about other applications;
>

This is not true. If you use a well-know format, such as tdb or sqlite,
libraries are readily available for reading them. Also, it's not a problem
for pcmanfm-qt.
Ideally this implementation detail should be done in libfm core. So other
programs using it should have access to the settings via APIs without
touching the underlying storage.


> 2) it is environment dependent (due to different paths for different
>     environments) - settings made in LXDE are not known for LXDE-Qt;
>

Yes, they'll be known by lxde-qt. The problem is the uris are not known by
kde. Other gio/gvfs using DEs should all know the paths/uris generated by
gio.
I don't see any problems here.


> 3) settings are specific to the machine, you cannot share settings for
>     the same folder over your office or whatever;
>
This is true. It's a limitation. Xattr has the same problem. Only
.directory approach solves this.


> 4) settings will be reset after folder is renamed;
>
Indeed, but if the renaming is done by libfm, we can handle it. If it's
not, then there is no way to update the data.


> 5) cannot set individual settings for two identical USB sticks, one of
>     which has videos and other has backup data, even if user strictly
>     wants to have them shown differently;
>

This is partially true. If you also store uuid of the device, then it's
solved.


> 6) centralized storage will slowly grow in size.
>

Distributed storage will grow as well, but you just don't know where they
are and how to clean them.


>
> Yes, it has bright sides too:
>
> 1) it can be used for read-only folders as well;
> 2) it isn't OS dependent;
> 3) it does not create any files in target folder.
>
> Do you think those drawbacks aren't important for our users?
>

Creating unwanted hidden files in the folders behind our back automatically
can be very annoying sometimes. It's a matter of taste. But I'm ok with
this solution as well since creating in-folder hidden config files is a
general practice and it's done by Mac and Windows for years.


>
> Well, about dual-handle settings I would like then to use approaches (1)
> and (3) together: if file .directory already exists then use it, if not
> then use own settings storage to keep settings. The approach (2) is not
> portable while (1) and (3) are, you know.
>

Yes, after thinking about it more, I think adding xttr can be too
complicated.
The only real benefit of it is no additional files are created and it's
fast to access without any db query. However, it's not easy to maintain and
may make things more complicated than they should be.

Try .directory first then fallback to our own cache just like dolphin seems
to be reasonable. Since there is no perfect solution I'm ok with less
optimized approaches given they work well.

Regards


>
>     With best regards.
>     Andriy.
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Pcmanfm-develop mailing list
> Pcm...@li...
> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
>