Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2010-10-25 16:07:52

On 10/25/2010 01:44 PM, Stewart, Robert wrote:
> Bjørn Roald wrote:
>    
>>
>> In any case I seriously think I may have missed points you have
>> made in other posts.  My statements was based om my
>> understanding of the issue, and not a good understanding of all
>> points made by others (including you) throughout this
>> discussion.
>>      
> OK.  Please do try to account for all others have posted when writing or, at least, when another refers you to earlier arguments, have the courtesy to review the earlier posts to find the claimed arguments rather than expecting them to be reiterated.
>    

Please stop this - this is not going anywhere.  It is not that I did not 
read a lot before posting, I can not see where you got that impression 
from.  In this particular discussion I recall reading some of your posts 
in other threads on the subject of a portable "My Documents" folder 
concept.  I just made the point that based on your reaction I thought 
there was a real chance I had missed something.  It may also be the case 
that none of your arguments struck me as significant enough to make me 
change my position om the subject that a valid home directory is a fine 
solution on POSIX platforms.   I do not intend to spend more time on 
this unless you point me to specifics.

>> Ok - we are discussing what a possible function returning the
>> "My Documents" would return on Linux/UNIX and possibly also OSX
>> platforms.  Let us call this the user_doc_dir concept.  This
>> concept cover a natural place for the user to organize private
>> documents.  The directory is generally not shared, although
>> most if not all systems will allow the users to make data
>> public and accessible by others.
>>      
> Good so far.
>
>    
>> First of all I have not attempted to dig into any details, so
>> there is likely to be variations on different Linux
>> distributions and UNIX systems. Also there are many solutions
>> for desktop environments which users to some extent can choose
>> freely among, so this is not easy.
>>      
> Agreed.  That's where I foresee that there is not going to be a single policy that will satisfy all clients, meaning that hard coding one into Filesystem will be problematic from a justification and maintenance standpoint.  To wit, a Trac issue is created asking, "Why isn't XYZ platform's configuration directory properly supported?"  Then, Beman will need to learn about that platform, may well discover that its convention conflicts with that of another platform making distinguishing one from the other impossible.  If that happens, what can he do but ostracize the requester -- and others using the XYZ platform -- by virtue of not being able to remove support for the platform already supported?
>    

Right.

>> 1.
>> Let us assume that there exist some known solutions where
>> user_doc_dir differ from the home directory.  If there exist
>> information about this boost::filesystem should check for this
>> first, if a valid path is found with read/write/execute
>> permissions, it should be used, else
>>      
> OK
>
>    
>> 2.
>> Parse /etc/passwd to find home directory of user, alternatively
>> check pwd command output or $PWD value in a fresh shell or
>> immediately after calling cd with no arguments, alternatively
>> check $HOME value, if a valid path is found with
>> read/write/execute permissions, it should be used, else
>>      
> That's a lot of work for what's (soon-to-be) a header only library, isn't it?  Still, it isn't unreasonable to expect.
>
>    
This was listing of 3 alternative methods of finding the home 
directory.  I do not now know which is better, it may be a different 
method all together on some targets or in general using POSIX 
standards.  But in any case - a header only solution should be feasible 
if desired.

>> 3.
>> signal failure
>>      
> OK
>
> That's good.  Previously, you were quite vague about what you thought should be included and simply argued against my use of the word, "default."  Now I have a better understanding of your thoughts.
>
>    
>>>> Hold on...  I write application zzzz.  I want to store
>>>> application data for that application in a subdirectory called
>>>> zzzz in a sensible place unique for each user on whatever
>>>> platform my code runs on.  I ask
>>>> boost::filesystem::user_appdata_dir for that.  If it return a
>>>> usable path, then I create the zzzz subdirectory if it is not
>>>> there already and store the data.  Later I can read or write
>>>> data in the same place with help of boost.  I do not need to
>>>> worry about how this could be different on a different
>>>> platform.  That is the whole point.
>>>>
>>>>          
>>> The convention on *nix systems is usually to create a .zzzz
>>> directory in the user's home directory, not a zzzz directory.
>>>        
>> Right, so it make sense to do a simple test if we are on a
>> POSIX system and make that dot caount :-)
>>      
                                               ^^^^^^
                                               dot count

> You stated previously that you'd use the zzzz directory; I pointed out the need for it being called the .zzzz directory.
>    

That  was my point when I tried to write that the dot should count  :-)

>    
>>>     Furthermore, a Windows application will store a good
>>> deal of information in the registry which has no equivalent
>>> elsewhere.  Consequently, the format, location, and layout of
>>> the configuration data will differ between the platforms.
>>>        
>> Right, I think the registry is more associated with
>> boost::program_options than boost::filesystem.  Nevertheless I
>> think complete and portable support of program_options concepts
>> in boost is lacking, especially as far as Windows Registery as
>> a database.  It is not clear to me what advantages the
>> repository provides over file based configurations except for
>> ordered locations for data, simple consistent API, and possibly
>> some expectations to well behaved applications.
>>
>> I think there may be standards for data in the Windows registry
>> supporting package management, windows installers, uninstallers
>> and so forth.  All modern OS/distros have similar databases for
>> package management, so I think use of the registry for storing
>> such package management data is orthogonal to use of registry
>> to store application data.
>>      
> You're suggesting that an application using Filesystem should be written with portability in mind so it will, of necessity, eschew proprietary things like the Windows registry whenever possible.  That may be reasonable, but it also makes such applications less like the norm for a given platform, right?
>    

Possibly yes. If it becomes too hard to avoid drifting away from the 
norm on any given platform, then it becomes a trade-off.  Not to 
following the platform norm is clearly not a goal for portable 
solutions, but sometimes it is the best overall solution.  As I stated, 
I think support for stuff like the Windows registry belongs in boost, 
but not in boost::filesystem.  Something like a future version of 
boost::program_options could use different solutions to store 
application settings data on different platforms according to platform 
norms. On windows it could default to using the registry while using 
configuration files in locations found with boost::filesystem on other 
platforms.

> My point was that the directory name was different, the file formats were very likely different, some data that would be in the app data directory on POSIX systems would likely be in the Windows registry and, for all I know, somewhere else on OS X, etc., so there are a great many differences that call into question its providing real portability, and thus whether Filesystem should support such a thing.
>    

Good points - however it is a real option for applications to ignore 
stuff like the Windows registry all together in the name of 
portability.  I am probably ignorant to a lot of important details, but 
think about it. If you ignore the assumption that the registry is the 
norm on Windows for storing application settings data and that other 
solutions are a bad, then what is really broken except for adherence to 
a perceived platform norm?  Who does really care?  If you do care - fine 
- then eat the pain and write platform dependent code.

>>> Why then, would Filesystem try to offer something so much
>>> different as a general concept across platforms?
>>>        
>> I have made many windows programs work without entries in
>> registry that I am aware of.  So I think it is mostly up to the
>> application author how much if any registry is required.  I for
>> one would find a user_appdata_dir function useful.
>>      
> OK.  There are certainly some applications for which that is appropriate.  The question is whether there are enough to make Filesystem support worthwhile.  I can't answer that question, but it should be asked.
>    

agreed.

-- 
Bjørn