Re: [boost] [filesystem] home_directory_path

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

On 10/27/2010 02:51 PM, Stewart, Robert wrote:
> Bjørn Roald wrote:
>    
>> On 10/26/2010 05:37 PM, Stewart, Robert wrote:
>>      
>>> 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.
>>      
> That was, traditionally, the same for C:\ on DOS/Windows.
>    

except for the fact that the whole system lived in that directory, not 
only personal data and settings.

>> 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.
>>      
> The analogy is by no means perfect, I admit.  The point is that there are many things comingled in one's home directory.  One has configuration files, application caches, scripts, possibly even some applications, so putting documents in the home directory itself is undesirable.  Providing something akin to My Documents is desirable, if there is any possibility of doing so.
>    

Agreed.

>>> 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.
>>      
> I can't parse that.
>    

yes, I can not parse it either.  But I know what was on my mind :-)

It seems GNOME and KDE both attempt to use the XDG (freedesktop 
standard) for these things.  My Kubuntu box has 
/etc/xdg/user-dirs.defaults with the following:

# Default settings for user directories
#
# The values are relative pathnames from the home directory and
# will be translated on a per-path-element basis into the users locale
DESKTOP=Desktop
DOWNLOAD=Downloads
TEMPLATES=Templates
PUBLICSHARE=Public
DOCUMENTS=Documents
MUSIC=Music
PICTURES=Pictures
VIDEOS=Videos
# Another alternative is:
#MUSIC=Documents/Music
#PICTURES=Documents/Pictures
#VIDEOS=Documents/Videos

And these folders are created as subfolders of home for new users.  I 
think GNOME on Ubuntu is the same, but I am not sure.

To some extent I have clearly been guided into using the Desktop and the 
Documents folder.  But in general most tools drops me as user in my home 
directory when I need to save something and I have my own long lived 
organization of data and have never paid attention to those other 
folders, hence they are empty.

Also, the GUI desktop has a large "Home" widget displaying the content 
of the home directory.

My conclusion is that except of the effects of files and folders dropped 
on the GUI desktop being mapped to the Desktop subdirectory of my home, 
the home directory itself is the top level concept for where the user is 
left alone.  I guess the rest of the folders more or less are just 
suggestion to an organization.
>>> 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.
>>      
> I have no concept of the authority of the spec you reference, but I do appreciate the idea of looking for something more specific and, if that fails, falling back on the home directory.  For a My Documents equivalent, this may be adequate as in either case, the directory is usable, if not ideal.  However, for an AppData equivalent, such an approach seems less useful because the user cannot be called upon to better direct the application.  That is, the home directory may not be the desired location and, if the XDG directory is not found, how is the user to direct the application to the desired location?
>
>    
>>> 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.
>>      
> I had AppData in mind as well as My Documents, though I only mentioned the latter.
>
>    
>>> 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 the app gets nothing from the My Documents query, then it branches into code that grabs the home directory and works from there.  This leaves the fallback policy in the application rather than Filesystem.  Of course, if the My Documents query returned the home directory, the application could query for the home directory, compare the two, and reach the same conclusion.
>
>    
>>> 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.
>> ...
>>      
> I was really confusing matters, because I had AppData in mind when I wrote My Documents there.
>
>    
>>> 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?
>>      
> First, you always want to push policy up to higher levels.  Therefore, when there's a policy choice, Filesystem shouldn't make it.  Filesystem can make selecting a given policy easy, but it shouldn't force one when there are choices available.  That's just good design.
>    

So far I agree if it means Filesystem select a default based on general 
knowledge and let the application override at will.

> Second, the application can choose a convention based upon the choice of the programmer or vendor.  IOW, if the app is supposed to target KDE, it will likely want to follow KDE's convention.  If the app wants to be XDG compliant, it will choose that convention.  If there is some more complicated, local convention supported by a particular developer or vendor, the application can write a function to effect that convention.
>
> Filesystem could follow widely supported standards and, if the indicated directory does not exist, return the home directory.  However, if instead it returned an empty path by default, clients would be forced to make a conscious choice of convention by setting the various directories using such functions as I've discussed so code querying those directories will get something useful.  Arguably, just returning the home directory doesn't prevent clients from setting the directories to something more conventional, but by not encouraging selection of a convention, it leads to somewhat poorer results from lazy programmers.
>    

I see your point, but I am not so sure this issue is hard enough for 
Filesystem to worry about the negative effects of lazy programmers, at 
least not to the extent you suggest.  But if it is good reason to 
worry,  and not feasible for Filesystem to make good policy choices, 
then I think your suggested approach should be considered.

Our discussion has probably not been very helpful in clearing the ground 
for an implementation.  There are clearly also some  postings against 
adding any of this to boost at all, so it is worth reviewing if it make 
sense to add it.  As usual someone have to step up and make a proposal 
covering at least Windows, Mac and Linux/Unix, and in this case with a 
reasonable set of runtime variants for each.   Maybe this is a sensible 
idea for a GSoC task, but it may be to light weight academically for 
that, I do not know.  Regrettably I can not help making a proposal, I 
would have liked to do that but I can not.

-- 
Bjørn