I imagined them never expiring. Just a place to put little preferences
and tidbits like api keys and usernames and passwords and whatever
else an app might need to remember. I imagined it as providing a
'cookies' method, which lazy loads the content of the yaml file, or if
it doesn't exist, empty hash, and then when that shoes app closes,
have the yaml file written if the hash exists and has changed since
when it loaded (same way the Camping Cookie Sessions checks for
changes). I think this would only be good if it could be implemented
on a per-app basis. Surely we can call an app a window which has no
parent, call it closed when the last window from that script is
closed. The only question left in my head is what do we use as a
unique identifier? Maybe just the script's filename? Maybe the
script's filename + the :title of the original app window, or maybe we
introduce an 'id' style to the app's main window, and say in the
manual to set it to a unique string, recommending that it either be a
http web address specific to that app, or the authors email address,
followed by a /, and then a unique app name type thing, or a tag uri
for bonus globally unique identifier points.
Whatever is used in the end, we could hash it and store it in hash.yaml
I really think the data (and all other shoes data) should go in ~/
Library/Application Data/Shoes/ on Mac OS X. As a mac user I find it
very frustrating that cross platform apps like to pollute my home
directory with hidden files and folders. It's just not how we do
things on Mac OS. User's should be able to navigate to Library,
Application Data, Shoes, and delete it if they like, or mess with it.
It should be visible, where using hidden files and folders in the home
directory cannot be seen with the Finder, forcing users to use the
Bash Terminal to manipulate them.
Final thought, would this be better?
• User calls 'cookies', receives empty hash, no matter what. User
sets :id to some string or symbol in the hash.
• User calls cookies again, this time cookies sees the :id in the
hash, and uses that to load the right file, merges in to hidden cookie
cache variable, returns reference to the hash again, now populated
• Last window from that script closes, part of unloading is writing
the file out to a yaml directory, after deleting :id from the hash.
Shoes.app { cookies[:id] = "Epona the Wonder Horse";
cookies[:highscores] |= []; cookies[:highscores].push("really high
one!") }
