Re: [boost] [filesystem] home_directory_path

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

Bjørn Roald wrote:
> On 10/22/2010 01:11 PM, Stewart, Robert wrote:
> > Bjørn Roald wrote:
> >
> > 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.
>
> I am not sure I follow all this.

I'm suggesting that Filesystem's core merely provides a means to set and vend directories, such as the home directory or the app data directory.  Most code will be written in terms of the vended values.  If Filesystem is queried for a value that wasn't set, it throws an exception.

Application initialization code, by contrast must set the directories for Filesystem to vend if other code is going to query them.  To do so, that initialization code chooses some convention for discovering the desired directories and calls an appropriate function that will use that convention and then set the directories for Filesystem to vend.  That approach means that Filesystem is open ended.  Any library client can devise a different convention either by replacing or augmenting existing functions that set the directories.

> How does this provide the ability to write simple, straight
> forward, and portable C++ in the spirit of boost?  When I refer
> to giving up, I refer to those goals.

I'm not certain anyone else agreed to those goals specifically, but they are reasonable, so certainly worth addressing.

The goal of simple code is achieved by making most code simply ask Filesystem for the desired directory.  The initialization code is complicated, relative to a hardcoded scheme built into Filesystem's initialization logic, by the need to pick a directory initialization function and calling it before querying the directories.  That's hardly difficult, but it is one step removed from the simplest interface possible.

The goal of straightforward code is achieved by the simplicity.  One calls one extra function that indicates the user directory convention desired.

   boost::filesystem::set_user_directories_default_convention();
   boost::filesystem::set_user_directories_xdg_convention();

The default convention might encode some set of rules thought to be most generally applicable across all platforms -- what you might otherwise hard code into Filesystem -- but that aren't completely acceptable to all concerned, thus making not hard coding them preferable.

The portability goal is achieved by the default convention, provided it is sufficient for a given client.  The XDG convention clearly applies only to systems that support that convention, so conditional compilation would be likely needed for portability, or a client might test the environment to choose that versus another initialization function at runtime.  Some other client may choose to write a custom function to set user directories according to local policies, which can be written with platform-specific logic inside the function, so that calling the one function during initialization accounts, portably, for the platform differences.

I hope this makes more sense to you now.

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