Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2010-10-26 17:50:23

On 10/26/2010 05:37 PM, Stewart, Robert wrote:
> Bjørn Roald wrote:
>    
> 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.
>>      
> "I may have missed points you have made in other posts."
>    

Note: Your quotations are above misleading, it looks like I wrote what 
you wrote and visa-versa.

  I see where you misinterpret me ;-)  If I say I have missed something 
then I tried to find it, I most likely read it, but failed to see the 
significance, or relevance.  In my book you can not miss something you 
are not looking for :-)

>> 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.
>>      
> Let me try making my points again, while incorporating subsequent
> ideas as well.  My Documents is a default location for various
> kinds of documents.  Windows users are notoriously naive because
> they come from so many walks of life, so it is common that
> everything be dumped in one place.

I see your point, but we may say the same about users of other operating 
systems as well.  I don't think windows users are generally more naive 
than others.

> Under earlier versions of
> Windows and DOS before that, users often dumped their files in
> the root directory of C:.

Sure, if nothing prevents it or guide them elsewhere.

> Thus, My Documents is a way to force
> stupid^H^H^H^H^H^Hnaive users to dump their files in a less
> hazardous location.

I do not like calling users stupid. Maybe even calling them naive is to 
strong.  Maybe it is more appropriate to state that programmers are 
clearly naive and stupid as they have so hard time figuring out how to 
make software the users can understand.

>   POSIX system users are typically less naive,
>    

maybe or maybe not

> though one reply mentioned the poster's wife as being in that
> class.
>    

> Given the undesirable organizational results, choosing the home
> directory as the equivalent implies the need to find something
> better.
>    

Better in what way?

> To my way of thinking, one's home directory is very similar to
> C:\ on a Windows system -- not counting Vista and Win7, given
> their greater strictures on accessing the drive -- in that one
> usually puts little in the home directory and, instead, creates
> one or more arbitrary directories into which files are put.

The main trait of the home directory is that it is personal, it belongs 
to one user.  As in others are generally not welcome to use it.  Whether 
security features exists or are set up to enforce that, is a different 
mather.  Make note that nothing prevents me from opening up full access 
to my home directory to anybody logged on:

 > chmod 777 /home/bjornr

One can question how smart that is, but that did not change /home/bjornr 
in any way so it is now not my home directory.

You are right that systems that does not know one user from another does 
generally not provide any help in organizing personal data either.  
Users on those machines have to do the job of organizing the filesystem 
all by themselves and the filesystem(s) are typically wide open and to 
their disposal - whether it is c:\ or anything else.  That does not make 
the complete file system a home directory as long as we do not assume or 
know the file system is completely personal.   We also know that the 
file system root most often is something else than the home directory, 
as it is the place the system data and programs live.

>    Now,
> with GUIs, there may well be an equivalent to My Documents, but
> only the applications written for that environment are likely to
> suggest it as a default location for saving a file.  For example,
> running a GNOME app under KDE is likely to refer to the GNOME
> default rather than to the KDE default (assuming both have one).
>    

They attempt to have a standard that differ as where the open desktop In 
fact both use the home directory.

> The foregoing suggests different locations for each GUI
>    
> plus
> arbitrary locations for other users.  Now add the XDG stuff
> mentioned in another post and you have yet another variation for
> the location.  Suppose you even try to account for the common GUI
> locations plus XDG.  If you find more than one, which should be
> selected?
>    

I think you try to make this more complicated than it needs to be.

For the concepts (if any) that boost::filesystem should support, we have 
the option to follow
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
and/or other similar systems depending on runtime and if that does not 
provide a solution, we can fall back to the home directory or something 
else that is an appropriate fall-back for the concept in question.

> Because of the above, the only common choice one can return on a
> POSIX system is the home directory and I find it a poor choice
> for a My Documents directory.  Consequently, I'd rather
> Filesystem returned nothing than the home directory.
>    

Given that many have pointed out that the only appropriate use of a My 
Documents directory concept is as default directory for Save As / File 
Open dialogs or file explorer like applications, then I see little 
reason to discredit the feasibility of the home directory as fallback 
solution as strongly as you do.

> Now, others have pointed out that most any location one would
> really want to use would be found under the home directory so, as
> a fallback, the home directory isn't so bad.

Ok, I guess we more or less agree then.

> Furthermore, it
> isn't Filesystem's job to babysit naive users; an application
> might choose to do something better.
>    

No its job is to babysit naive programmers and their stupid applications :-)

> Does returning the home directory actually help provide
> portability?  I don't think so.  Given that Filesystem cannot
> decide among multiple choices when discovered (as described for
> multiple GUI equivalents plus XDG, all of which may exist), an
> application that calls a My Documents accessor won't know whether
> it is My Documents on a Windows system or the home directory to
> which some app-specific or vendor-specific subdirectory should be
> appended.
>    

Applications should never add data to My Documents, only users shall.

> Thus, I'd rather Filesystem return nothing when there is no
> obvious choice.  Then, the application can learn that there is no
> path available from Filesystem, query for the home directory, and
> do the app-specific or vendor-specific work from that known
> point.
>    

Ok, we are back where we started and as always anything is possible, but 
what known point are you referring to?

> If an application is written with generic portability in mind,
> then it would retrieve the home directory and add app-specific or
> vendor-specific subdirectories to locate the application-related
> documents, ignoring the My Documents directory on Windows.  Such
> an app does not require an accessor for a My Documents type
> directory in Filesystem.
>    

Some apps may:
File Open
File Save As
Explorer type apps
Apps searching for and indexing user files, photos, music, etc.
...

But you are right, there may be more important stuff to have in 
boost::filesystem.

> My conclusion is that Filesystem should not provide a My
> Documents type directory unless there is an obviously good choice
> on the current system.  IOW, it could include some complicated
> search for various environment-specific directories and, if there
> is a unique answer, return that but otherwise it should declare
> an ambiguity or failure to find an appropriate directory.
>    

That is one possible solution, but it depend on your definition of the 
concept.  You idea is to require the concept to represent the one and 
only unique user document directory for the current user.  Another 
possibility is that the concept represent a directory that is 
appropriate as a document directory for the current user.   Yet another, 
a list of appropriate directories.  It all depend on what is needed.

> Going back to my idea of calling a particular function to assert
> the desired convention, failure to find a conforming directory
> could result in creating the directory.  It certainly would
> remove the decision Filesystem would otherwise be obliged to make
> of disambiguating among choices or forcing a potentially
> undesirable default.
>    

This may be a good idea, I am just struggling a bit with this as it 
seems we are just pushing the difficult and tricky decision back on the 
application.  How shall the application determine which convention to use?

-- 
Bjørn