Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Mamatha Busi via swift-corelibs-dev]

Hello Created a PR https://github.com/apple/swift-corelibs-foundation/pull/889 for the XDG file specification implementation, extending from the work Tony Parker shared below. 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.Any other ideas to get the tests done? Thanks!CheersMamatha-swift-corelibs-dev-boun...@swift.org wrote: -To: Pushkar N Kulkarni From: Tony Parker via swift-corelibs-dev Sent by: swift-corelibs-dev-boun...@swift.orgDate: 01/23/2017 11:08PMCc: Will Stanton , swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageHere is the branch where I started the work but didn’t get too far.https://github.com/parkera/swift-corelibs-foundation/tree/parkera/xdg_implementationOne tricky part is that we need to figure out a way to test this stuff without exposing public API from file manager…- TonyOn Jan 23, 2017, at 2:09 AM, Pushkar N Kulkarni  wrote:Hi Tony, Thanks! A starting point will really help. I've filed a feature request on JIRA: https://bugs.swift.org/browse/SR-3697Pushkar N Kulkarni,IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra-anthony.par...@apple.com wrote: -To: Pushkar N Kulkarni From: Tony Parker Sent by: anthony.par...@apple.comDate: 01/20/2017 11:28PMCc: Will Stanton , swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageYup, 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.- TonyOn Jan 20, 2017, at 2:31 AM, Pushkar N Kulkarni  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 RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra-swift-corelibs-dev-boun...@swift.org wrote: -To: Will Stanton From: Tony Parker via swift-corelibs-dev Sent by: swift-corelibs-dev-boun...@swift.orgDate: 11/17/2016 03:45AMCc: swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageHi Will,> On Nov 14, 2016, at 12:56 PM, Will Stanton  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=Code=✓) 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  wrote:>> >> Off-list, someone pointed me here:>> >> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>> >> and here:>> >> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix>> >> Noting that there seems to be a growing consensus for $HOME/.config.>> >> Is this spec beginning to be used in the real world?> ___swift-corelibs-dev mailing 

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Pushkar N Kulkarni via swift-corelibs-dev]

Hi Tony, Thanks! A starting point will really help. I've filed a feature request on JIRA: https://bugs.swift.org/browse/SR-3697Pushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
-anthony.par...@apple.com wrote: -To: Pushkar N Kulkarni From: Tony Parker Sent by: anthony.par...@apple.comDate: 01/20/2017 11:28PMCc: Will Stanton , swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageYup, 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.- TonyOn Jan 20, 2017, at 2:31 AM, Pushkar N Kulkarni  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 RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra-swift-corelibs-dev-boun...@swift.org wrote: -To: Will Stanton From: Tony Parker via swift-corelibs-dev Sent by: swift-corelibs-dev-boun...@swift.orgDate: 11/17/2016 03:45AMCc: swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageHi Will,> On Nov 14, 2016, at 12:56 PM, Will Stanton  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=Code=✓) 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  wrote:>> >> Off-list, someone pointed me here:>> >> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>> >> and here:>> >> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix>> >> Noting that there seems to be a growing consensus for $HOME/.config.>> >> Is this spec beginning to be used in the real world?> ___swift-corelibs-dev mailing listswift-corelibs-dev@swift.orghttps://lists.swift.org/mailman/listinfo/swift-corelibs-dev


___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Tony Parker via swift-corelibs-dev]

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...@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-boun...@swift.org 
> <mailto:-swift-corelibs-dev-boun...@swift.org> wrote: -
> To: Will Stanton <willstant...@yahoo.com <mailto:willstant...@yahoo.com>>
> From: Tony Parker via swift-corelibs-dev 
> Sent by: swift-corelibs-dev-boun...@swift.org 
> <mailto:swift-corelibs-dev-boun...@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 <willstant...@yahoo.com 
> > <mailto:willstant...@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=Code= 
> > <https://github.com/search?q=XDG_DATA_HOME=Code=>✓) 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:
> >> 
> >> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> >>  
> >> <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>
> >> 
> >> and here:
> >> 
> >> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix
> >>  
> >> <http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix>
> >> 
> >> Noting that there seems to be a growing consensus for $HOME/.config.
> >> 
> >> Is this spec beginning to be used in the real world?
> > 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Pushkar N Kulkarni via swift-corelibs-dev]

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 RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
-swift-corelibs-dev-boun...@swift.org wrote: -To: Will Stanton From: Tony Parker via swift-corelibs-dev Sent by: swift-corelibs-dev-boun...@swift.orgDate: 11/17/2016 03:45AMCc: swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageHi Will,> On Nov 14, 2016, at 12:56 PM, Will Stanton  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=Code=✓) 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  wrote:>> >> Off-list, someone pointed me here:>> >> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>> >> and here:>> >> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix>> >> Noting that there seems to be a growing consensus for $HOME/.config.>> >> Is this spec beginning to be used in the real world?> ___swift-corelibs-dev mailing listswift-corelibs-dev@swift.orghttps://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Tony Parker via swift-corelibs-dev]

Hi Will,

> On Nov 14, 2016, at 12:56 PM, Will Stanton  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=Code=✓) 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 
>>  wrote:
>> 
>> Off-list, someone pointed me here:
>> 
>> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>> 
>> and here:
>> 
>> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix
>> 
>> Noting that there seems to be a growing consensus for $HOME/.config.
>> 
>> Is this spec beginning to be used in the real world?
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Will Stanton via swift-corelibs-dev]

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=Code=✓) 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 
>  wrote:
> 
> Off-list, someone pointed me here:
> 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> 
> and here:
> 
> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix
> 
> Noting that there seems to be a growing consensus for $HOME/.config.
> 
> Is this spec beginning to be used in the real world?

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Itai Ferber via swift-corelibs-dev]

>From my (potentially limited) experience, I would say that yes, many tools out 
>there do follow this spec.
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`.

On 14 Nov 2016, at 11:37, Tony Parker via swift-corelibs-dev wrote:

>
>> On Nov 14, 2016, at 10:47 AM, Will Stanton  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!
>>
>
> Off-list, someone pointed me here:
>
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
> and here:
>
> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix
>
> 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  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.
>>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


signature.asc
Description: OpenPGP digital signature
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Tony Parker via swift-corelibs-dev]

> On Nov 14, 2016, at 10:47 AM, Will Stanton  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!
> 

Off-list, someone pointed me here:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

and here:

http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix

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

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Will Stanton via swift-corelibs-dev]

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


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

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Philippe Hausler via swift-corelibs-dev]

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 <willstant...@yahoo.com <mailto:willstant...@yahoo.com>> 
>> wrote: -
>> To: Pushkar N Kulkarni/India/IBM@IBMIN
>> From: Will Stanton <willstant...@yahoo.com <mailto:willstant...@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?
>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Pushkar N Kulkarni via swift-corelibs-dev]

Thanks Will! "NSHomeDirectory() + "/.foundation/Cookies/shared" seems good to mePushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
-Will Stanton  wrote: -To: Pushkar N Kulkarni/India/IBM@IBMINFrom: Will Stanton Date: 11/08/2016 08:45AMCc: swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorageWas 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  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?

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Kenny Leung via swift-corelibs-dev]

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 
>  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 
>>  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?
>> 
>> In my current implementation 
>> (https://github.com/apple/swift-corelibs-foundation/pull/672), I write them 
>> to a hidden plist file located in the user's home directory. Would that be 
>> an acceptable approach?
>> 
>> Is there anything more to consider while thinking of persistence? I'd 
>> greatly appreciate suggestions/comments. 
>> 
>> Thanks!
>> Pushkar N Kulkarni,
>> IBM Runtimes
>> 
>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Tony Parker via swift-corelibs-dev]

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 
>  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?
> 
> In my current implementation 
> (https://github.com/apple/swift-corelibs-foundation/pull/672) 
> , I write them 
> to a hidden plist file located in the user's home directory. Would that be an 
> acceptable approach?
> 
> Is there anything more to consider while thinking of persistence? I'd greatly 
> appreciate suggestions/comments. 
> 
> Thanks!
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Implementing HTTPCookieStorage

[Pushkar N Kulkarni via swift-corelibs-dev]

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?In my current implementation (https://github.com/apple/swift-corelibs-foundation/pull/672), I write them to a hidden plist file located in the user's home directory. Would that be an acceptable approach?Is there anything more to consider while thinking of persistence? I'd greatly appreciate suggestions/comments. Thanks!Pushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra


___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev