Implementing HTTPCookieStorage


(Pushkar N Kulkarni) #1

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


(Tony Parker) #2

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?

In my current implementation (https://github.com/apple/swift-corelibs-foundation/pull/672) <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


(Kenny Leung) #3

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?

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


(Will Stanton) #4

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?


(Pushkar N Kulkarni) #5

Thanks Will!

"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”

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?

-----Will Stanton willstanton1@yahoo.com wrote: -----


(Tony Parker) #6

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?

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


(Philippe Hausler) #7

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?

_______________________________________________
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


(Will Stanton) #8

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


(Tony Parker) #9

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 :slight_smile:
- 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

···

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.


(Itai Ferber) #10

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

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


(Will Stanton) #11

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?

Regards,
Will Stanton

···

On Nov 14, 2016, at 2:37 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> 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?


(Tony Parker) #12

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.

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

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?


(Pushkar N Kulkarni) #13

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

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.

  • 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:

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

To: Will Stanton willstanton1@yahoo.com
From: Tony Parker via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org
Date: 11/17/2016 03:45AM
Cc: swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

-----swift-corelibs-dev-bounces@swift.org wrote: -----


(Tony Parker) #14

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> 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:
>>
>> 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 <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Pushkar N Kulkarni) #15

Hi Tony,

Thanks! A starting point will really help.

I’ve filed a feature request on JIRA: https://bugs.swift.org/browse/SR-3697

Pushkar N Kulkarni,

IBM Runtimes

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.

  • 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

Hi Will,

On Nov 14, 2016, at 12:56 PM, Will Stanton 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=✓) 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 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

To: Will Stanton willstanton1@yahoo.com
From: Tony Parker via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org
Date: 11/17/2016 03:45AM
Cc: swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

-----swift-corelibs-dev-bounces@swift.org wrote: -----

To: Pushkar N Kulkarni pushkar.nk@in.ibm.com
From: Tony Parker
Sent by: anthony.parker@apple.com
Date: 01/20/2017 11:28PM
Cc: Will Stanton willstanton1@yahoo.com, swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

Yup, I think that makes sense.

-----anthony.parker@apple.com wrote: -----


(Tony Parker) #16

Here is the branch where I started the work but didn’t get too far.

https://github.com/parkera/swift-corelibs-foundation/tree/parkera/xdg_implementation

One tricky part is that we need to figure out a way to test this stuff without exposing public API from file manager…

- Tony

···

On Jan 23, 2017, at 2:09 AM, Pushkar N Kulkarni <pushkar.nk@in.ibm.com> wrote:

Hi Tony,

Thanks! A starting point will really help.

I've filed a feature request on JIRA: https://bugs.swift.org/browse/SR-3697

Pushkar N Kulkarni,
IBM Runtimes

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:
>>
>> 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 <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Mamatha Busi) #17

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.

Thanks!

-Mamatha

IBM Runtimes.

https://github.com/parkera/swift-corelibs-foundation/tree/parkera/xdg_implementation

One tricky part is that we need to figure out a way to test this stuff without exposing public API from file manager…

  • Tony
···

On Jan 23, 2017, at 2:09 AM, Pushkar N Kulkarni pushkar.nk@in.ibm.com wrote:

Hi Tony,

Thanks! A starting point will really help.

I’ve filed a feature request on JIRA: https://bugs.swift.org/browse/SR-3697

Pushkar N Kulkarni,

IBM Runtimes

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.

  • 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

Hi Will,

On Nov 14, 2016, at 12:56 PM, Will Stanton 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=✓) 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 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

To: Will Stanton willstanton1@yahoo.com
From: Tony Parker via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org
Date: 11/17/2016 03:45AM
Cc: swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

-----swift-corelibs-dev-bounces@swift.org wrote: -----

To: Pushkar N Kulkarni pushkar.nk@in.ibm.com
From: Tony Parker
Sent by: anthony.parker@apple.com
Date: 01/20/2017 11:28PM
Cc: Will Stanton willstanton1@yahoo.com, swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

Yup, I think that makes sense.

-----anthony.parker@apple.com wrote: -----


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

To: Pushkar N Kulkarni pushkar.nk@in.ibm.com
From: Tony Parker via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org
Date: 01/23/2017 11:08PM
Cc: Will Stanton willstanton1@yahoo.com, swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

Here is the branch where I started the work but didn’t get too far.

-----swift-corelibs-dev-bounces@swift.org wrote: -----


(Pushkar N Kulkarni) #18

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 :slight_smile:

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.

Thanks!

-Mamatha

IBM Runtimes.

https://github.com/parkera/swift-corelibs-foundation/tree/parkera/xdg_implementation

One tricky part is that we need to figure out a way to test this stuff without exposing public API from file manager…

  • Tony
···

On Jan 23, 2017, at 2:09 AM, Pushkar N Kulkarni pushkar.nk@in.ibm.com wrote:

Hi Tony,

Thanks! A starting point will really help.

I’ve filed a feature request on JIRA: https://bugs.swift.org/browse/SR-3697

Pushkar N Kulkarni,

IBM Runtimes

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.

  • 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

Hi Will,

On Nov 14, 2016, at 12:56 PM, Will Stanton 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=✓) 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 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

To: Will Stanton willstanton1@yahoo.com
From: Tony Parker via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org
Date: 11/17/2016 03:45AM
Cc: swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

-----swift-corelibs-dev-bounces@swift.org wrote: -----

To: Pushkar N Kulkarni pushkar.nk@in.ibm.com
From: Tony Parker
Sent by: anthony.parker@apple.com
Date: 01/20/2017 11:28PM
Cc: Will Stanton willstanton1@yahoo.com, swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

Yup, I think that makes sense.

-----anthony.parker@apple.com wrote: -----


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

To: Pushkar N Kulkarni pushkar.nk@in.ibm.com
From: Tony Parker via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org
Date: 01/23/2017 11:08PM
Cc: Will Stanton willstanton1@yahoo.com, swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

Here is the branch where I started the work but didn’t get too far.

To: Tony Parker anthony.parker@apple.com
From: Mamatha Busi/India/IBM
Date: 02/01/2017 10:35PM
Cc: Pushkar N Kulkarni/India/IBM@IBMIN, Will Stanton willstanton1@yahoo.com, swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

-----swift-corelibs-dev-bounces@swift.org wrote: -----

-----Mamatha Busi/India/IBM wrote: -----


(Mamatha Busi) #19

Hello

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!

Cheers

Mamatha

-----swift-corelibs-dev-bounces@swift.org wrote: -----

https://github.com/parkera/swift-corelibs-foundation/tree/parkera/xdg_implementation

One tricky part is that we need to figure out a way to test this stuff without exposing public API from file manager…

  • Tony
···

On Jan 23, 2017, at 2:09 AM, Pushkar N Kulkarni pushkar.nk@in.ibm.com wrote:

Hi Tony,

Thanks! A starting point will really help.

I’ve filed a feature request on JIRA: https://bugs.swift.org/browse/SR-3697

Pushkar N Kulkarni,

IBM Runtimes

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.

  • 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

Hi Will,

On Nov 14, 2016, at 12:56 PM, Will Stanton 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=✓) 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 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

To: Will Stanton willstanton1@yahoo.com
From: Tony Parker via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org
Date: 11/17/2016 03:45AM
Cc: swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

-----swift-corelibs-dev-bounces@swift.org wrote: -----

To: Pushkar N Kulkarni pushkar.nk@in.ibm.com
From: Tony Parker
Sent by: anthony.parker@apple.com
Date: 01/20/2017 11:28PM
Cc: Will Stanton willstanton1@yahoo.com, swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

Yup, I think that makes sense.

-----anthony.parker@apple.com wrote: -----


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

To: Pushkar N Kulkarni pushkar.nk@in.ibm.com
From: Tony Parker via swift-corelibs-dev
Sent by: swift-corelibs-dev-bounces@swift.org
Date: 01/23/2017 11:08PM
Cc: Will Stanton willstanton1@yahoo.com, swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

Here is the branch where I started the work but didn’t get too far.

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.