Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-27 08:51:47

Bjørn Roald wrote:
> On 10/26/2010 05:37 PM, Stewart, Robert wrote:
> >
> > 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.

Windows covers vastly more desktops than any other OS.  It has been the de facto standard for most everyone with a desktop computer and, therefore, has included all manner of naive computer users.  The landscape is changing in recent years, but the historical penetration of Windows (and DOS before that) is undeniable.  Microsoft decided to do something to encourage those users to do what they should have been doing all along: not putting everything in C:\.  I have seen that very thing too many times to count and have had to educate many users away from that practice.  My hope is to avoid encouraging something like Window's/DOS's original state with one's home directory.

> > 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.

I by no means suggested that every Windows user was stupid or naive.  However, Windows does have a greater share of them because it has a greater share of users generally and because most other OSes require (until recently, anyway) a good deal greater knowledge (MacOS/OS X excepted).

> >   POSIX system users are typically less naive,
>
> maybe or maybe not

Today, there are increasing numbers of naive users of Linux, certainly, but the vast majority are still far more savvy.

> > Given the undesirable organizational results, choosing the home
> > directory as the equivalent implies the need to find something
> > better.
>
> Better in what way?

In a way that leads to better organizing one's files.

> > 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.

> 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.

> > 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.

> > 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.

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.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.