On Mon, 2006-11-20 at 21:16 -0400, Devan Goodwin wrote:
> I'm looking to migrate to Revelation and write an importer for my
> previous password solution (Palm SplashID).
Cool :) If you don't mind, I'd like to initially include a version of
your data handler which won't require file format changes. The other
data handler do this by cramming the data into Revelations existing
fields, like putting notes into the description field etc.
> I notice a couple things
> missing or that I would like to have in place before attempting that
> import, most if not all of which seem to be on the TODO list.
> 1. Notes stored on entries.
> 2. Configurable entry types.
Yes - I've actually started spec'ing a new file format which allows for
this. You can read a draft of it here:
It's pretty rough, and everything in it is subject to change. Also, the
encryption section is somewhat outdated, as I'll most likely be using
LUKS as a crypto backend.
> The following are my proposals for behavior and a variety of
> questions. Feedback would be greatly appreciated.
> * Entry types stored in a separate XML file in ~/.revelation/.
> Considered storing the types encrypted in the actual safe, but it
> seems to me like the kind of thing you might want to share across
> safes. Perhaps I could store it in the safe and allow just a type
> export/import feature.
Yeah, I agree - the custom account types should probably be stored as
configuration data (ie, in ~/.revelation/) and not in the safe, but we
might consider merging these with account types found in the current
safe. This needs some careful thought.
> * If no type information is found or we're creating a new safe, the
> default types will be created matching the ones that exist now.
There's alot of room for improvements in the default types, I've listed
some suggestions in the spec draft but these are likely to change.
> * Add assumption that an entry points to a type and contains an
> independent list of strings corresponding to it's fields. Something
> <name>Friendly Name</name>
> So basically, a field on an entry is just a string, a field on an
> entry type carries all the information about how to display it, and we
> combine the two in the UI. I think this would be most useful for
> converting from one type to another. Entries with more fields than
> their type actually defines would just be displayed differently in the
> UI. (i.e. 'Unknown field: val')
I think the format defined in the spec draft solves this better, but
feel free to suggest improvements (radical or not).
> * Detect an old save file (i.e. the current format) and prompt to
> upgrade when the Revelation is started.
I think we should just do this silently.
> I guess that's it so far, I've just begun reading the code so I'm sure
> more questions will arise, but I was wondering if the above changes
> sound reasonable and if there's any interest in a patch for such
If you're volunteering to implement a new file format, then by all
means, patches are most welcome :) However, it needs to be carefully
spec'ed first - I want this format to be usable for a long time without
Erik Grinaker <[EMAIL PROTECTED]>
"We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
-- Albert Einstein