The non centralized storage has another one drawback:
If multiple users have write permission on the directory (for example it's
mounted nfs or smb share) then the one user will overwrite the settings of
another.
2013/11/7 Andrej N. Gritsenko <[email protected]>
> Hello!
>
> [email protected] has written on Thursday, 7 November, at 17:38:
> >On Thu, Nov 07, 2013 at 05:59:16PM +0200, Andrej N. Gritsenko wrote:
> >> 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;
> >> 2) it is environment dependent (due to different paths for different
> >> environments) - settings made in LXDE are not known for LXDE-Qt;
>
> >I guess #2 is due to the fact that it is different programs who
> potentially
> >use it, thus the same as #1.
>
> >> 3) settings are specific to the machine, you cannot share settings for
> >> the same folder over your office or whatever;
>
> >Unclear what you mean here. My (and many others') home directory is
> >available on all machines I am using, with the same shared contents. A
> >file-based storage somewhere under $HOME/.something would be working fine
> >(as long as the implementation does not do something innapropriate,
> >i.e. specifically incompatible with shareability). That's why I would
> >dismiss #3 as well.
>
> Well, you have folder ~/Video available on machine A and you set it to
> use Thumbnails View mode. On machine B you have default view mode as
> Detailed List View. You can get that folder opened on the machine B as
> sftp://A/home/user/Video. Guess how it will be shown on machine B? If you
> think it will be in Thumbnails View mode then you've failed. It will be
> shown in Detailed List View mode. User may expect it to be shown in the
> Thumbnails View on machine B, C, etc. That can be achieved though with
> .directory approach only.
>
> >> 4) settings will be reset after folder is renamed;
>
> >Not if the rename is done via the same file manager (otherwise yes).
>
> Well, we should put hooks everywhere to handle that, that will bloat the
> file manager (who dare to call it lightweight after that?). And also you
> wrote yourself, that is only if you rename via the same file manager and
> that isn't always the case, a lot of users use a lot of different tools.
> So we shouldn't do it in the file manager either, for consistency and to
> keep it still lightweight.
>
> >> 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;
>
> >Why? As long as the settings refer to the sticks' hardware (and unique)
> >identifier they will be separate. I tried already to explain this.
> >Thus #5 is not valid either.
>
> Unfortunately, we never refer to sticks' hardware, we don't work with the
> hardware directly but we use GVFS, and the same stick will have generic
> name such as 'USB Dongle 16GB'. Trying to retrieve hardware identifier
> and use it back and forth means we should add few hooks, bloating the
> code again. I'm heavily against any code bloating as I said, I stay on
> the KISS principle - if that cannot be done simply then it should not be
> done at all.
>
> >> 6) centralized storage will slowly grow in size.
>
> >But not indefinitely, mostly as large as to correspond to the user's
> needs,
> >even with a simplistic garbage collector.
> >The information storage volume would be roughly the same for all of
> >the approaches.
>
> Well, it will be a bit bigger for some folders that were gone but file
> manager does not know yet about it. Though it is very little difference
> so I should agree with you, it may be safely ignored.
>
> >Thus I can not agree with #6.
>
> >This leaves us:
>
> >1) it is application dependent
> >2) if the user renames a folder by a different program or from a separate
> > $HOME then the setting for the folder get lost
>
> >> Do you think those drawbacks aren't important for our users?
>
> >Talking as a system administrator for quite a few computers and users:
> >I believe that this would be better for my users than properties of the
> >other two approaches.
>
> Thank you very much for sharing your opinion!
>
> >Thanks for working on this Andriy!
>
> >(I guess this is the spelling of your name which you prefer, I didn't
> >think about it when I used the one from the mail header, sorry for that)
>
> Nothing to be sorry for. In fact, both those names are right, just in
> different languages (Russian and Ukrainian) that I communicate the most.
> I just like the Ukrainian language a bit more, that's all. :)
>
> >Regards,
> >Rune
>
> 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
> _______________________________________________
> Lxde-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lxde-list
>
--
Best regards,
Alexander.
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Pcmanfm-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
