Re: [boost] [filesystem] home_directory_path

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

On 10/25/2010 01:44 PM, Stewart, Robert wrote:
> 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.
>    

Ok, if this was available in boost I had too set these values just in 
case something is using them.  I do not know if this is worth it.

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

Yes, and if that code can make reasonable assumption the call to 
Filesystem will return  a usable directory, or fail, then this is fine, 
else all simplicity is gone.  Right?

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

Ok,  I think I get what you are after here.  So basically this is 
optional features that if used give some control back to the user of 
selected aspects of how boost::filesystem behaves - right?   
Interresting idea.  If simpler solutions are no good, then this may be 
the way too go.

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

It does, thanks.

-- 
Bjørn