Ok I'll keep an eye out. Will be nice to see your prototype to get an idea where you want it to go.
Cheers, Devan On 12/12/06, Erik Grinaker <[EMAIL PROTECTED]> wrote:
On Mon, 2006-12-04 at 20:29 -0400, Devan Goodwin wrote: > On 12/3/06, Erik Grinaker <[EMAIL PROTECTED]> wrote: > > On Mon, 2006-11-20 at 21:16 -0400, Devan Goodwin wrote: > > > * 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? Actually, that wouldn't be a problem. The importer for old Revelation files would be hardcoded with the old entry types, and just create new-style entries with the same names and fields if they're found in the file. However, come to think of it, this would actually recreate the default account types in the users configuration, as Revelation will necessarily have to know about the account types in order to display and handle them. In any case, it's a minor problem, and not one we should worry about when designing the new file format. The quality and flexibility of the new file format is the primary concern, handling old files is really more of a detail (ie, it has to be done somehow, but I don't think it would be a big deal to implement in any case). I'll probably figure something out when I start working on the importer. > > > * Add assumption that an entry points to a type and contains an > > > independent list of strings corresponding to it's fields. Something > > > like: <snip> > > > > > 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) I'm assuming you mean Fieldtype and Typename? Well, fieldtype is supposed to be a sort of identifier for the field, so Revelation can do stuff with the various fields - such as use their values in launchers. Typename is a human-readable name for the field, which is to be used for labels when displaying and editing it. The reason we have to store both, is because when users can create their own account types and then move the file to a different computer, Revelation don't know anything about the accounts or fields, and won't know what name to use for labels, so we have to include it. But when I think about it, this could be solved alot better by including the whole account database in the data file, and just using fieldtype to map it to a definition in the account type list. It is bit redundant to store both fieldtype, typename, and datatype for each and every field with the same fieldtype, so something is clearly wrong with the current draft. > > > * 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. As mentioned before, this shouldn't really be a problem. > > > 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. > > 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 > application. Awesome! I'm gonna start working actively on Revelation again very soon, I'm planning to do a 0.4.8 release this week and then go ahead with the new file format and everything it entails. The code base will be undergoing major changes when I start this work, so I think the best thing is to just focus on the file specification for now, until I get a prototype ready. -- Erik Grinaker <[EMAIL PROTECTED]> http://erikg.codepoet.no/ "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
-- Devan Goodwin <[EMAIL PROTECTED]> http://dgoodwin.dangerouslyinc.com
