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