>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 <willstant...@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.par...@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
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
