<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">From my (potentially limited) experience, I would say that yes, many tools out there do follow this spec.<br>
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. <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">~/.vimrc</code>, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">~/.emacs.d</code>, etc.). Someone with more immediate access to a Linux box can maybe help back this up.</p>
<p dir="auto">I personally like this convention, and think it's a safe option. We are highly unlikely to conflict with anything in <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">~/.config</code> or <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">~/.local</code>.</p>
<p dir="auto">On 14 Nov 2016, at 11:37, Tony Parker via swift-corelibs-dev wrote:</p>
<p dir="auto"></p></div>
<div style="white-space:pre-wrap"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div dir="auto">
</div><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><div dir="auto">On Nov 14, 2016, at 10:47 AM, Will Stanton <willstanton1@yahoo.com> wrote:
</div><div dir="auto">
</div><div dir="auto">Hello Tony and Philippe,
</div><div dir="auto">
</div><div dir="auto">I don’t think it would be odd for cookie/setting files to be in a folder named after Foundation (namely ~/.foundation):
</div><div dir="auto">- 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.
</div><div dir="auto">- 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.
</div><div dir="auto">‘.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.
</div><div dir="auto">And, executable name seems reasonable in lieu of bundle ID.
</div><div dir="auto">
</div><div dir="auto">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).
</div><div dir="auto">
</div></blockquote><div dir="auto">
</div><div dir="auto">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.
</div><div dir="auto">
</div><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><div dir="auto">
</div><div dir="auto">Am interested in alternatives of course :-)
</div><div dir="auto">- But having separate folders for each app seems complicated, ex. '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
</div><div dir="auto">- I don’t really mind the name of an encapsulating folder, .foundation or otherwise.
</div><div dir="auto">- 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!
</div><div dir="auto">
</div></blockquote><div dir="auto">
</div><div dir="auto">Off-list, someone pointed me here:
</div><div dir="auto">
</div><div dir="auto"><a href="https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html" style="color:#777">https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html</a>
</div><div dir="auto">
</div><div dir="auto">and here:
</div><div dir="auto">
</div><div dir="auto"><a href="http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix" style="color:#777">http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix</a>
</div><div dir="auto">
</div><div dir="auto">Noting that there seems to be a growing consensus for $HOME/.config.
</div><div dir="auto">
</div><div dir="auto">Is this spec beginning to be used in the real world?
</div><div dir="auto">
</div><div dir="auto">- Tony
</div><div dir="auto">
</div><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><div dir="auto">
</div><div dir="auto">To Philippe’s points about security+future-proofing:
</div><div dir="auto">Perhaps the cookie file could be named per version of its format:
</div><div dir="auto">~/.foundation/Cookies/shared initially
</div><div dir="auto">When we have a new format:
</div><div dir="auto">~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name entirely?
</div><div dir="auto">
</div><div dir="auto">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?).
</div><div dir="auto">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?)
</div><div dir="auto">
</div><div dir="auto">Regards,
</div><div dir="auto">Will Stanton
</div><div dir="auto">
</div><blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><div dir="auto">On Nov 14, 2016, at 12:44 PM, Tony Parker <anthony.parker@apple.com> wrote:
</div><div dir="auto">
</div><div dir="auto">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.
</div></blockquote><div dir="auto">
</div></blockquote><div dir="auto">
</div><div dir="auto">_______________________________________________
</div><div dir="auto">swift-corelibs-dev mailing list
</div><div dir="auto">swift-corelibs-dev@swift.org
</div><div dir="auto"><a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" style="color:#777">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev</a>
</div></blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>