I have spent some time working on a basic implementation of HTTPCookieStorage. In the process, I came across two crucial questions related to cookie persistence:
Good question. If this were Darwin I guess I would say ~/Library/Application Support — but I don’t know what the best practices are on other platforms. Does anyone out there have some suggestions?
- Tony
···
On Nov 7, 2016, at 11:09 AM, Pushkar N Kulkarni via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Hi there,
I have spent some time working on a basic implementation of HTTPCookieStorage. In the process, I came across two crucial questions related to cookie persistence:
1. How do you persist the cookies?
2. Where do you persist them?
I’m for locating it in the same place on all platforms. In general, I’m tired of digging around in different places for stuff depending on which flavor I’m using.
-Kenny
···
On Nov 7, 2016, at 2:45 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Hi Pushkar,
Good question. If this were Darwin I guess I would say ~/Library/Application Support — but I don’t know what the best practices are on other platforms. Does anyone out there have some suggestions?
- Tony
On Nov 7, 2016, at 11:09 AM, Pushkar N Kulkarni via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Hi there,
I have spent some time working on a basic implementation of HTTPCookieStorage. In the process, I came across two crucial questions related to cookie persistence:
1. How do you persist the cookies?
2. Where do you persist them?
Was wondering if there could be a common directory for Foundation-related files, such as NSUserDefaults in addition to cookie storage?
So maybe for cookies:
NSHomeDirectory() + "/.foundation/Cookies/shared"
And settings for an app/service:
NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist"
And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond handles cookies… or caches things, but I think I agree with Kenny that naming symmetry would be nice if there is a per-user cookies file.
So having a /Library may be nicer, but potentially unnecessary?
NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something"
Regards,
Will Stanton
···
On Nov 7, 2016, at 5:45 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Hi Pushkar,
Good question. If this were Darwin I guess I would say ~/Library/Application Support — but I don’t know what the best practices are on other platforms. Does anyone out there have some suggestions?
"NSHomeDirectory() + "/.foundation/Cookies/shared" seems good to me
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
···
To: Pushkar N Kulkarni/India/IBM@IBMIN
From: Will Stanton willstanton1@yahoo.com
Date: 11/08/2016 08:45AM
Cc: swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
Was wondering if there could be a common directory for Foundation-related files, such as NSUserDefaults in addition to cookie storage?
So maybe for cookies:
NSHomeDirectory() + "/.foundation/Cookies/shared"
And settings for an app/service:
NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist"
And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond handles cookies… or caches things, but I think I agree with Kenny that naming symmetry would be nice if there is a per-user cookies file.
So having a /Library may be nicer, but potentially unnecessary?
NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something"
Good question. If this were Darwin I guess I would say ~/Library/Application Support — but I don’t know what the best practices are on other platforms. Does anyone out there have some suggestions?
Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when Foundation is just one of the libraries involved? On Darwin, the prefs are organized by application, not by framework.
- Tony
···
On Nov 14, 2016, at 1:43 AM, Pushkar N Kulkarni via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Thanks Will!
"NSHomeDirectory() + "/.foundation/Cookies/shared" seems good to me
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
-----Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>> wrote: -----
To: Pushkar N Kulkarni/India/IBM@IBMIN
From: Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>>
Date: 11/08/2016 08:45AM
Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>>
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
Was wondering if there could be a common directory for Foundation-related files, such as NSUserDefaults in addition to cookie storage?
So maybe for cookies:
NSHomeDirectory() + "/.foundation/Cookies/shared"
And settings for an app/service:
NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist"
And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond handles cookies… or caches things, but I think I agree with Kenny that naming symmetry would be nice if there is a per-user cookies file.
So having a /Library may be nicer, but potentially unnecessary?
NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something"
Regards,
Will Stanton
> On Nov 7, 2016, at 5:45 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>
> Hi Pushkar,
>
> Good question. If this were Darwin I guess I would say ~/Library/Application Support — but I don’t know what the best practices are on other platforms. Does anyone out there have some suggestions?
Furthermore isn’t it a bit of a conflict if we have multiple versions of Foundation running apps on a server? I would expect that the mutable state of cookies should never be shared across processes not just from a security standpoint but also from a versioning standpoint.
Let have a scenario where there are two web apps running on the same server. They should never share data between them unless specifically allowed to. Service A uses Foundation version A and service B uses version B. Unless service A and B have privileges to communicate they should never use common storage for cookies or preferences. This could allow service A to inappropriately use the stored credentials of service B if they are stored in the same directory. Moreover if the version B of Foundation has some refinement to the storage version of the cookie the file may be incompatible with Foundation A’s reading schema.
In my opinion the directories should be unique to the services running unless they share a system based privilege system that is a common version (e.g. they are allowed to talk to each other and are not sandboxed apart).
Of course some of this could be side-stepped by having the services running as different users. But the versioning issue still occurs and should perhaps be something that we consider.
···
On Nov 14, 2016, at 9:44 AM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when Foundation is just one of the libraries involved? On Darwin, the prefs are organized by application, not by framework.
- Tony
On Nov 14, 2016, at 1:43 AM, Pushkar N Kulkarni via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
Thanks Will!
"NSHomeDirectory() + "/.foundation/Cookies/shared" seems good to me
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
-----Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>> wrote: -----
To: Pushkar N Kulkarni/India/IBM@IBMIN
From: Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>>
Date: 11/08/2016 08:45AM
Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>>
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
Was wondering if there could be a common directory for Foundation-related files, such as NSUserDefaults in addition to cookie storage?
So maybe for cookies:
NSHomeDirectory() + "/.foundation/Cookies/shared"
And settings for an app/service:
NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist"
And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond handles cookies… or caches things, but I think I agree with Kenny that naming symmetry would be nice if there is a per-user cookies file.
So having a /Library may be nicer, but potentially unnecessary?
NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something"
Regards,
Will Stanton
> On Nov 7, 2016, at 5:45 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>
> Hi Pushkar,
>
> Good question. If this were Darwin I guess I would say ~/Library/Application Support — but I don’t know what the best practices are on other platforms. Does anyone out there have some suggestions?
I don’t think it would be odd for cookie/setting files to be in a folder named after Foundation (namely ~/.foundation):
- The files are owned by Swift/Linux Foundation in the sense Foundation writes them, and Foundation is the only one that should access them directly. Foundation should enforce security.
- On macOS, settings seem to be written to ~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed ~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different.
‘.foundation’ is used in lieu of a library directory, and I feel this is acceptable so as not to clash with any user ~/Preferences or ~/Library directory. I am OK with the ‘Foundation ownership’ per above.
And, executable name seems reasonable in lieu of bundle ID.
I noted something like ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist may be desirable to keep symmetry/reuse more CF code, but changing Swift CF is probably necessary anyway and better (fewer search paths to loop through, possibly less I/O).
Am interested in alternatives of course :-)
- But having separate folders for each app seems complicated, ex. '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
- I don’t really mind the name of an encapsulating folder, .foundation or otherwise.
- Placing system configuration files in /etc is a norm, but I think I’d feel more comfortable with Swift app settings in /home/user (easier to keep track of, and I can delete the whole thing without consequences*). I’m also not writing any real low-level services in Swift… but others probably are… but they probably have their own code to write config data to /etc!
To Philippe’s points about security+future-proofing:
Perhaps the cookie file could be named per version of its format:
~/.foundation/Cookies/shared initially
When we have a new format:
~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name entirely?
I also think it should be up to Swift Foundation to enforce cookie security on a per-app/family basis (the latter requires changes to the package structure?).
Perhaps for now, it is possible to save the hash and name of the executable storing a cookie? And Foundation can load cookie storage only if the executable name and file haven’t changed? (Is that an unnecessary pain?)
Regards,
Will Stanton
···
On Nov 14, 2016, at 12:44 PM, Tony Parker <anthony.parker@apple.com> wrote:
Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when Foundation is just one of the libraries involved? On Darwin, the prefs are organized by application, not by framework.
I don’t think it would be odd for cookie/setting files to be in a folder named after Foundation (namely ~/.foundation):
- The files are owned by Swift/Linux Foundation in the sense Foundation writes them, and Foundation is the only one that should access them directly. Foundation should enforce security.
- On macOS, settings seem to be written to ~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed ~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different.
‘.foundation’ is used in lieu of a library directory, and I feel this is acceptable so as not to clash with any user ~/Preferences or ~/Library directory. I am OK with the ‘Foundation ownership’ per above.
And, executable name seems reasonable in lieu of bundle ID.
I noted something like ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist may be desirable to keep symmetry/reuse more CF code, but changing Swift CF is probably necessary anyway and better (fewer search paths to loop through, possibly less I/O).
Agreed, I don’t have any problem with baking a set of rules into CF that is specific to various platforms. That’s it’s job after all.
Am interested in alternatives of course :-)
- But having separate folders for each app seems complicated, ex. '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
- I don’t really mind the name of an encapsulating folder, .foundation or otherwise.
- Placing system configuration files in /etc is a norm, but I think I’d feel more comfortable with Swift app settings in /home/user (easier to keep track of, and I can delete the whole thing without consequences*). I’m also not writing any real low-level services in Swift… but others probably are… but they probably have their own code to write config data to /etc!
Noting that there seems to be a growing consensus for $HOME/.config.
Is this spec beginning to be used in the real world?
- Tony
···
On Nov 14, 2016, at 10:47 AM, Will Stanton <willstanton1@yahoo.com> wrote:
To Philippe’s points about security+future-proofing:
Perhaps the cookie file could be named per version of its format:
~/.foundation/Cookies/shared initially
When we have a new format:
~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name entirely?
I also think it should be up to Swift Foundation to enforce cookie security on a per-app/family basis (the latter requires changes to the package structure?).
Perhaps for now, it is possible to save the hash and name of the executable storing a cookie? And Foundation can load cookie storage only if the executable name and file haven’t changed? (Is that an unnecessary pain?)
Regards,
Will Stanton
On Nov 14, 2016, at 12:44 PM, Tony Parker <anthony.parker@apple.com> wrote:
Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when Foundation is just one of the libraries involved? On Darwin, the prefs are organized by application, not by framework.
I only have anecdotal evidence to back this up, but I think many new tools use this convention, and those that don't do not out of long-standing conventions that say otherwise (e.g. `~/.vimrc`, `~/.emacs.d`, etc.). Someone with more immediate access to a Linux box can maybe help back this up.
I personally like this convention, and think it's a safe option. We are highly unlikely to conflict with anything in `~/.config` or `~/.local`.
···
From my (potentially limited) experience, I would say that yes, many tools out there do follow this spec.
On 14 Nov 2016, at 11:37, Tony Parker via swift-corelibs-dev wrote:
On Nov 14, 2016, at 10:47 AM, Will Stanton <willstanton1@yahoo.com> wrote:
Hello Tony and Philippe,
I don’t think it would be odd for cookie/setting files to be in a folder named after Foundation (namely ~/.foundation):
- The files are owned by Swift/Linux Foundation in the sense Foundation writes them, and Foundation is the only one that should access them directly. Foundation should enforce security.
- On macOS, settings seem to be written to ~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed ~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different.
‘.foundation’ is used in lieu of a library directory, and I feel this is acceptable so as not to clash with any user ~/Preferences or ~/Library directory. I am OK with the ‘Foundation ownership’ per above.
And, executable name seems reasonable in lieu of bundle ID.
I noted something like ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist may be desirable to keep symmetry/reuse more CF code, but changing Swift CF is probably necessary anyway and better (fewer search paths to loop through, possibly less I/O).
Agreed, I don’t have any problem with baking a set of rules into CF that is specific to various platforms. That’s it’s job after all.
Am interested in alternatives of course :-)
- But having separate folders for each app seems complicated, ex. '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
- I don’t really mind the name of an encapsulating folder, .foundation or otherwise.
- Placing system configuration files in /etc is a norm, but I think I’d feel more comfortable with Swift app settings in /home/user (easier to keep track of, and I can delete the whole thing without consequences*). I’m also not writing any real low-level services in Swift… but others probably are… but they probably have their own code to write config data to /etc!
Noting that there seems to be a growing consensus for $HOME/.config.
Is this spec beginning to be used in the real world?
- Tony
To Philippe’s points about security+future-proofing:
Perhaps the cookie file could be named per version of its format:
~/.foundation/Cookies/shared initially
When we have a new format:
~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name entirely?
I also think it should be up to Swift Foundation to enforce cookie security on a per-app/family basis (the latter requires changes to the package structure?).
Perhaps for now, it is possible to save the hash and name of the executable storing a cookie? And Foundation can load cookie storage only if the executable name and file haven’t changed? (Is that an unnecessary pain?)
Regards,
Will Stanton
On Nov 14, 2016, at 12:44 PM, Tony Parker <anthony.parker@apple.com> wrote:
Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when Foundation is just one of the libraries involved? On Darwin, the prefs are organized by application, not by framework.
Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations.
Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=✓\) and am not opposed to it!
Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?
What about the path for cookies+caches?
Regards,
Will Stanton
···
On Nov 14, 2016, at 2:37 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations.
Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=✓\) and am not opposed to it!
Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?
What about the path for cookies+caches?
I’m just reading this spec for the first time, but it looks like it accounts for that:
• There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME.
Overall the spec looks reasonable and seems to be close to what we we would need.
A great next step would be to file a JIRA and look for volunteers who want to help implement this in SCL-Foundation.
- Tony
···
On Nov 14, 2016, at 12:56 PM, Will Stanton <willstanton1@yahoo.com> wrote:
Regards,
Will Stanton
On Nov 14, 2016, at 2:37 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
I hope we still agree on the use of the "XDG Base Directory Specification". I did a quick read of the spec document.
I am happy to file a JIRA report for this.
The scope, as I understand it is: CoreFoundation will implement the "XDG Base Directory Specification" and present an API to allow Foundation to retrieve the different absolute paths(related to the different env variables defined), which will be used to persist the different kinds of user data.
Please do let me know if my understanding is correct. Please augment it if necessary.
Thanks!
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
Hi Will,
Hello Tony,
Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations.
Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=✓) and am not opposed to it!
Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?
What about the path for cookies+caches?
I’m just reading this spec for the first time, but it looks like it accounts for that:
• There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME.
Overall the spec looks reasonable and seems to be close to what we we would need.
A great next step would be to file a JIRA and look for volunteers who want to help implement this in SCL-Foundation.
I started an implementation a bit ago but didn’t get very far before I got derailed onto some other topics. I’ll see if I can clean it up and put it somewhere as a starting point.
- Tony
···
On Jan 20, 2017, at 2:31 AM, Pushkar N Kulkarni <pushkar.nk@in.ibm.com> wrote:
Hi Tony, Will, others:
Apologies for bringing this up after a long time!
I hope we still agree on the use of the "XDG Base Directory Specification". I did a quick read of the spec document.
I am happy to file a JIRA report for this.
The scope, as I understand it is: CoreFoundation will implement the "XDG Base Directory Specification" and present an API to allow Foundation to retrieve the different absolute paths(related to the different env variables defined), which will be used to persist the different kinds of user data.
Please do let me know if my understanding is correct. Please augment it if necessary.
Thanks!
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
-----swift-corelibs-dev-bounces@swift.org <mailto:-----swift-corelibs-dev-bounces@swift.org> wrote: -----
To: Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>>
From: Tony Parker via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org <mailto:swift-corelibs-dev-bounces@swift.org>
Date: 11/17/2016 03:45AM
Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>>
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
Hi Will,
> On Nov 14, 2016, at 12:56 PM, Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>> wrote:
>
> Hello Tony,
>
> Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations.
> Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8= <https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=>✓\) and am not opposed to it!
>
> Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?
>
>
> What about the path for cookies+caches?
I’m just reading this spec for the first time, but it looks like it accounts for that:
> • There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME.
Overall the spec looks reasonable and seems to be close to what we we would need.
A great next step would be to file a JIRA and look for volunteers who want to help implement this in SCL-Foundation.
- Tony
>
> Regards,
> Will Stanton
>
>> On Nov 14, 2016, at 2:37 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>
>> Off-list, someone pointed me here:
>>
>> XDG Base Directory Specification
>>
>> and here:
>>
>> Location of ini/config files in linux/unix? - Stack Overflow
>>
>> Noting that there seems to be a growing consensus for $HOME/.config.
>>
>> Is this spec beginning to be used in the real world?
>
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
I started an implementation a bit ago but didn’t get very far before I got derailed onto some other topics. I’ll see if I can clean it up and put it somewhere as a starting point.
I hope we still agree on the use of the "XDG Base Directory Specification". I did a quick read of the spec document.
I am happy to file a JIRA report for this.
The scope, as I understand it is: CoreFoundation will implement the "XDG Base Directory Specification" and present an API to allow Foundation to retrieve the different absolute paths(related to the different env variables defined), which will be used to persist the different kinds of user data.
Please do let me know if my understanding is correct. Please augment it if necessary.
Thanks!
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations.
Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=✓) and am not opposed to it!
Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?
What about the path for cookies+caches?
I’m just reading this spec for the first time, but it looks like it accounts for that:
• There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME.
Overall the spec looks reasonable and seems to be close to what we we would need.
A great next step would be to file a JIRA and look for volunteers who want to help implement this in SCL-Foundation.
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
-----anthony.parker@apple.com <mailto:-----anthony.parker@apple.com> wrote: -----
To: Pushkar N Kulkarni <pushkar.nk@in.ibm.com <mailto:pushkar.nk@in.ibm.com>>
From: Tony Parker
Sent by: anthony.parker@apple.com <mailto:anthony.parker@apple.com>
Date: 01/20/2017 11:28PM
Cc: Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>>, swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>>
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
Yup, I think that makes sense.
I started an implementation a bit ago but didn’t get very far before I got derailed onto some other topics. I’ll see if I can clean it up and put it somewhere as a starting point.
- Tony
On Jan 20, 2017, at 2:31 AM, Pushkar N Kulkarni <pushkar.nk@in.ibm.com <mailto:pushkar.nk@in.ibm.com>> wrote:
Hi Tony, Will, others:
Apologies for bringing this up after a long time!
I hope we still agree on the use of the "XDG Base Directory Specification". I did a quick read of the spec document.
I am happy to file a JIRA report for this.
The scope, as I understand it is: CoreFoundation will implement the "XDG Base Directory Specification" and present an API to allow Foundation to retrieve the different absolute paths(related to the different env variables defined), which will be used to persist the different kinds of user data.
Please do let me know if my understanding is correct. Please augment it if necessary.
Thanks!
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
-----swift-corelibs-dev-bounces@swift.org <mailto:-----swift-corelibs-dev-bounces@swift.org> wrote: -----
To: Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>>
From: Tony Parker via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org <mailto:swift-corelibs-dev-bounces@swift.org>
Date: 11/17/2016 03:45AM
Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>>
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
Hi Will,
> On Nov 14, 2016, at 12:56 PM, Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>> wrote:
>
> Hello Tony,
>
> Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations.
> Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8= <https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=>✓\) and am not opposed to it!
>
> Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?
>
>
> What about the path for cookies+caches?
I’m just reading this spec for the first time, but it looks like it accounts for that:
> • There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME.
Overall the spec looks reasonable and seems to be close to what we we would need.
A great next step would be to file a JIRA and look for volunteers who want to help implement this in SCL-Foundation.
- Tony
>
> Regards,
> Will Stanton
>
>> On Nov 14, 2016, at 2:37 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>>
>> Off-list, someone pointed me here:
>>
>> XDG Base Directory Specification
>>
>> and here:
>>
>> Location of ini/config files in linux/unix? - Stack Overflow
>>
>> Noting that there seems to be a growing consensus for $HOME/.config.
>>
>> Is this spec beginning to be used in the real world?
>
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
I started an implementation a bit ago but didn’t get very far before I got derailed onto some other topics. I’ll see if I can clean it up and put it somewhere as a starting point.
I hope we still agree on the use of the "XDG Base Directory Specification". I did a quick read of the spec document.
I am happy to file a JIRA report for this.
The scope, as I understand it is: CoreFoundation will implement the "XDG Base Directory Specification" and present an API to allow Foundation to retrieve the different absolute paths(related to the different env variables defined), which will be used to persist the different kinds of user data.
Please do let me know if my understanding is correct. Please augment it if necessary.
Thanks!
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations.
Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=✓) and am not opposed to it!
Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?
What about the path for cookies+caches?
I’m just reading this spec for the first time, but it looks like it accounts for that:
• There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME.
Overall the spec looks reasonable and seems to be close to what we we would need.
A great next step would be to file a JIRA and look for volunteers who want to help implement this in SCL-Foundation.
In my opinion, cookies should go into $XDG_DATA_HOME
But, there was an opinion sometime back, that cookies could go into a .config directory. So, I am wondering if $XDG_CONFIG_HOME is also a candidate here :-)
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
Hello
@Tony:
Thanks for sharing. I would like to build upon it from here.
@all
I need guidance on which XDG environment directory path the cookie storage would fit in?
Would XDG_CONFIG_HOME be a best fit for the cookies?
Request your inputs to put me in the right direction.
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
I started an implementation a bit ago but didn’t get very far before I got derailed onto some other topics. I’ll see if I can clean it up and put it somewhere as a starting point.
I hope we still agree on the use of the "XDG Base Directory Specification". I did a quick read of the spec document.
I am happy to file a JIRA report for this.
The scope, as I understand it is: CoreFoundation will implement the "XDG Base Directory Specification" and present an API to allow Foundation to retrieve the different absolute paths(related to the different env variables defined), which will be used to persist the different kinds of user data.
Please do let me know if my understanding is correct. Please augment it if necessary.
Thanks!
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations.
Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=✓) and am not opposed to it!
Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?
What about the path for cookies+caches?
I’m just reading this spec for the first time, but it looks like it accounts for that:
• There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME.
Overall the spec looks reasonable and seems to be close to what we we would need.
A great next step would be to file a JIRA and look for volunteers who want to help implement this in SCL-Foundation.
But still the question remains as to how we could test this without adding exposed API from the Foundation side.
We could identify the usage of the XDG Environmental variables in already existing API of Foundation. For example: HTTPCookieStorage would use XDG_CONFIG_HOME or XDG_DATA_HOME. Although, not sure that we can find usage for the entire specification.
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
I started an implementation a bit ago but didn’t get very far before I got derailed onto some other topics. I’ll see if I can clean it up and put it somewhere as a starting point.
I hope we still agree on the use of the "XDG Base Directory Specification". I did a quick read of the spec document.
I am happy to file a JIRA report for this.
The scope, as I understand it is: CoreFoundation will implement the "XDG Base Directory Specification" and present an API to allow Foundation to retrieve the different absolute paths(related to the different env variables defined), which will be used to persist the different kinds of user data.
Please do let me know if my understanding is correct. Please augment it if necessary.
Thanks!
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations.
Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=✓) and am not opposed to it!
Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config?
What about the path for cookies+caches?
I’m just reading this spec for the first time, but it looks like it accounts for that:
• There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME.
Overall the spec looks reasonable and seems to be close to what we we would need.
A great next step would be to file a JIRA and look for volunteers who want to help implement this in SCL-Foundation.