Hi Erik, thanks for the great response,

On 12/3/06, Erik Grinaker <[EMAIL PROTECTED]> wrote:
Hi Devan!

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.

Good idea. I've been slowly working on the features I mentioned since
I first wrote, but I like the idea of putting that on hold and
reverting to the current code base to implement a quick SplashID CSV
parser. I will submit this first.

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

Just to clarify the problem you're referring to here, the situation
where a user starts the application and has no custom defined account
types, so the application loads the default types and stores them as
XML in ~/.revelation. User can now modify them as they see fit. User
attempts to open an old safe, we detect this and transparently convert
their entries to the new file format and autosave. I suspect you're
worried about a situation where the user has modified the default
types and the migration can no longer take place?

> * 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
> like:
> <entryType>
>  <id>someid</id>
>  <name>Friendly Name</name>
>  <icon>icon</icon>
>  <openicon>openicon</openicon>
>  <fields>
>    <field>
>      <name>Username</name>
>      <type>StringField</type>
>    </field>
>  </fields>
> </entryType>
> <entry>
>  <type>someid</type>
>  <fields>
>    <field>myloginname</field>
>  </fields>
> </entry>
> 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).

Agreed, your spec looks much more well thought out. I haven't gone
through it completely, but I'll start thinking about it heavily and
hopefully start implementing. (one question I did have was the purpose
of both Typename and Datatype)

> * 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.

Sounds good. Might have to prompt for user interaction in the case of
the problem I referred to above (assuming I have the right problem in
mind), but otherwise transparent sounds great.

> 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
> functionality.

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
any changes.

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
enthusiastic about."
                                                  -- Albert Einstein

I am indeed volunteering. :) I'll be happy to work with you and any
other developers involved to make sure it meets your standards. I've
been coding in a private repository for a little while now, I have
some readjusting to do in light of the information you provided in
this email. Thanks for the great response, and kudos on a very useful



Devan Goodwin <[EMAIL PROTECTED]>

Reply via email to