Persistent data with starkits and starpacks

irrational <[email protected]> Sun, 22 Feb 2009 20:16:12 -0800 (PST)
Newsgroups gmane.comp.lang.tcl.starkit
Message-ID <350266b9-fcf8-46a4-b32c-5d38f0a22615@p20g2000yqi.googlegroups.com>
Can someone confirm that I am not being stupid about this. And if not,
then can someone suggest what to do with persistent data.

I want to distribute an application for multiple platforms using
starpacks, because they are nice simple clickable applications that
can reside anywhere. The application needs to keep a small amount of
data that is persistent across sessions, in fact the data essentially
gets set by the user once the first time its used and remains with
application unchanged for future sessions.

My intention was to keep the data in a file in the application's vfs
using simple open, puts, close in the first session, and then accessed
with open, gets thereafter.

First, I wrapped the App.vfs into a starkit App.kit with sdx.kit using
the writable flag. Invoking the application as tclkit App.kit, the
settings data was saved and was there to use at each new session.
Good.

Then I wrapped the App.vfs into a starpack with sdx.kit now specifying
a copy of a tclkit binary for the required platform and using writable
flag. Invoking the starpack application the data I want to retain is
being set, but does not get saved when the application is closed. Each
session behaves like a first session.

My guess is that unlike the App.kit starkit, which is a file on the
disk that gets updated on writing to the vfs, the starpack is in
memory and is not ever written back to disk. This makes sense I guess,
one doesn't really want an application changing itself, that could
have nasty consequences.

I conclude then that if I want persistent data across sessions I have
to either (1) distribution as a starkit, or (2) write the persistent
data out to a file somewhere in OS file system.

The problem with (1) is my users are not savvy and need a simple
clickable application. Preferably with a sweet little icon.

The problem with (2) is where to put the data? Every OS has different
conventions, user areas and privileges, etc. Any suggestions on this,
surely others have deal with this before?

K.