[swift-corelibs-dev] Implementing HTTPCookieStorage

[Itai Ferber]

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 <willstanton1 at yahoo.com> wrote:
>>
>> Hello Tony and Philippe,
>>
>> I don’t think it would be odd for cookie/setting files to be in a folder named after Foundation (namely ~/.foundation):
>> - The files are owned by Swift/Linux Foundation in the sense Foundation writes them, and Foundation is the only one that should access them directly. Foundation should enforce security.
>> - On macOS, settings seem to be written to ~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed ~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different.
>> ‘.foundation’ is used in lieu of a library directory, and I feel this is acceptable so as not to clash with any user ~/Preferences or ~/Library directory.  I am OK with the ‘Foundation ownership’ per above.
>> And, executable name seems reasonable in lieu of bundle ID.
>>
>> I noted something like ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist may be desirable to keep symmetry/reuse more CF code, but changing Swift CF is probably necessary anyway and better (fewer search paths to loop through, possibly less I/O).
>>
>
> Agreed, I don’t have any problem with baking a set of rules into CF that is specific to various platforms. That’s it’s job after all.
>
>>
>> Am interested in alternatives of course :-)
>> - But having separate folders for each app seems complicated, ex. '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
>> - I don’t really mind the name of an encapsulating folder, .foundation or otherwise.
>> - Placing system configuration files in /etc is a norm, but I think I’d feel more comfortable with Swift app settings in /home/user (easier to keep track of, and I can delete the whole thing without consequences*). I’m also not writing any real low-level services in Swift… but others probably are… but they probably have their own code to write config data to /etc!
>>
>
> 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20161114/9afc916d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20161114/9afc916d/attachment.sig>