Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-22 07:11:32

Bjørn Roald wrote:
> On 10/21/2010 02:15 PM, Stewart, Robert wrote:
> > Bjørn Roald wrote:
> >> On 10/20/2010 01:33 PM, Stewart, Robert wrote:
>
> I said "I see no reason", I still do not see any.  But I may
> be blind ;-)

I have given reasons.  You may say you find them insufficient, but even with the qualifier, "I see absolutely no reason," dismisses the rationale I've given out of hand.

> Defaults too me means you always have a value, you never fail
>  to provide one.  Sure some value types may have a convention
>  for an invalid value, if used as default you could signal
>  failure trough it.

That's what I understood you to be saying all along: return the home directory.  I now understand, from the following, that you have implied a distinction that was not clear to me.

> > You contend that the fallback, in this case, is the home
> > directory.  That's the default.
>
> Absolutely not.  There is no way you can be sure there is a
> valid home directory for the current user - so how can that be
> a default.  You have to test a few thinks, if that fails to
> find a valid home directory, then the only sensible alternative
> is to return that fact to the caller.

So far, despite your suggestion that there are a few things to test, I understand you to be saying return the home directory, provided it exists.  If it doesn't exist, then signal an error (likely via exception).  If there are other things to check before signaling an error, please be explicit about what you mean.

> for my notion of concepts here, the following apply:
>
> posix_home_dir  is a user_doc_dir
> posix_home_dir  is a user_profile_dir
> posix_home_dir  is also other things that may be mapped to
> useful concepts
>
> user_doc_dir is not a user_profile_dir and vice versa
> hence neither of those two concepts are a posix_home_dir
> it follows that there is no equalence between user_doc_dir and
> posix_home_dir, but we still have that posix_home_dir  is a
> user_doc_dir
>
> The point is that the posix_home_dir serves fine as a user_doc_dir
> without being the same thing by every letter of the law.

Thank you.  I understand the distinction you were trying to make now.

> >>>     The AppData "folder" on Windows has no equivalent on
> >>> POSIX systems.
> >>>
> >> Why not?  For the same concept as the Windows users
> >> AppData on POSIX systems the home directory works just fine.
> >> I have many directories in my Linux home directory containing
> >> application data for their respective applications. Many of
> >> these applications put their data in hidden files/directories
> >> to avoid polluting the home directory too much, but it is the
> >> standard solution as far as I can tell.
> >>
> > AppData is a rather structured, common location, away from
> > other directories, that well-behaved applications are
> > supposed to use.  On POSIX systems, there is no common
> > storage approach for data of that sort.  Given that the
> > manner in which such data is stored differs on the two
> > platforms, there's no reason to suppose that the two
> > directories will offer anything useful between the two
> > platforms.  Since everything about that data is platform
> > specific, there is no point in Filesystem providing an
> > accessor for such directories.
>
> 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.  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.  Why then, would Filesystem try to offer something so much different as a general concept across platforms?

I have no experience with Macs, so I don't know how such data is managed on that platform, but I suspect it will be different in non-trivial ways from Windows and *nix.

> >> The tricky part here is to come up with the desired concepts
> >> we want support for in boost::filesystem and then determine
> >> if there is a good solution on each relevant runtime
> >> platform.  Looking for defined equivalence is the same as
> >> giving up.  Then we will gain nothing.
> >>
> > I have no idea what you're saying because that reads as,
> > "find the desired concepts to support and look for a good
> > default, but doing so is the same as giving up."
>
> Where did you get "good default" from?

I paraphrased from "good solution" and my reading of your earlier ideas as really being defaults.  Since you've continued to dislike "default" as I'm applying it, s/default/solution/ and you get the same result to my mind.

> I try to rephrase my intended message:
>
> Finding a perfect solution is impossible, so we should just
> give up.  Or --- maybe, if we can find something that is very
> valuable and useful for boost::filesystem users, then we can
> accept a few scratches in the paint.

Ah, I understand you now, but I consider that a false dichotomy, presuming you mean abandon home_directory_path() in frustration by "give up."  There are two additional choices, at least.  One is to determine a thing as too little generalizable as to be the purview of Filesystem, which isn't the same as giving up.  Another is to decide that there is no good default behavior on which people can agree, so the right behavior is to require that the value be supplied by the user so that Filesystem is merely the vehicle for vending that value.

As to the latter approach, note that Filesystem could even offer several functions a user can call to establish the values it vends.  For example, there might be a function for POSIX systems that discovers the user's home directory, validates it, and then sets it as the Filesystem home directory, configuration directory, etc., according to your notions.  There could be another that establishes some other common convention used on certain Linux distributions, for example.  There could be a function that establishes WinXP conventions, another for Win7, and yet another for WinCE conventions.  Thus, the user can take advantage of prepackaged code, if appropriate and available, or write custom code to set the Filesystem values according to some local convention.

Given that approach to establishing the values vended by Filesystem, all other user code can simply query Filesystem for the values when needed, being thus ignorant of what convention was set during initialization, while Filesystem avoids encouraging any given convention over another.

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