> 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
