Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-26 11:37:18

Bjørn Roald wrote:
> 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.

"I may have missed points you have made in other posts."

> 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.  Under earlier versions of
Windows and DOS before that, users often dumped their files in
the root directory of C:.  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.  POSIX system users are typically less naive,
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.

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

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?

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.

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.  Furthermore, it
isn't Filesystem's job to babysit naive users; an application
might choose to do something better.

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.

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.

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.

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.

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.

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