On Sun, 25 Feb 2007 22:39:12 +0900, Erik Grinaker <[EMAIL PROTECTED]> wrote:
(original message mercilessly snipped) > > What happens if I delete a field from an account type? Is the field > > going to be deleted from the accounts regardless that there might be > > content in it? > > Yes, the field will be deleted from all accounts, of course after > warning the user about this. But we might include an "Only delete > empty fields" checkbox in the warning dialog, which would remove the > field if empty and convert the field to a custom field if it has any > contents. This is my major concern. Account types should be used ONLY as a reference; changing the account type should not retroactively go back and shaft everything I've already set up until this point. An account is a free-standing entity; it has all the information that the user cares about. If the account type file should go away, some less-important things (e.g., the default icon) might go away, but nothing crazy would happen (e.g., all the accounts get deleted; can't open the keyring; etc.). Again, the account type should be used for reference purposes only -- it's "presentation" data, NOT "structural" data. In the absence of an account, sane defaults should be used. Use case: I transfer my keyring to a new computer, which doesn't have my account type files. Revelation should open the keyring, politely remind me that I may need to transfer my account type data from the old machine, and then proceed to show me my accounts. Everything should work in the absence of the account type files. > > For account type changes, it would be something like this: > > - Add field: also add the field to all accounts linked to the type. This should happen "for free." Revelation reads an account, looks up the linked account type, puts all the fields from the account type on the screen, fills in the values from the specific account, then adds any extra fields from the account that aren't specified by the account type. Empty fields from the account type simply aren't saved with the account data. > - Edit field: edit the field on all accounts linked to the type which > has this field (ie, where an individual account didn't have the field > removed). Bulk edit is better suited for this. Field names belong with the data, because we lose information if the account is separated from its stylesheet (account type) otherwise. Converting fields should generally not be allowed, as it could lead to data loss and/or create inconsistent states. Data loss should be the #1 concern with an application of this nature, and data availability should be a close #2. > - Remove field: remove the field on all accounts linked to the type > which has the field, optionally with a choice to keep fields which > have content (converted to custom field). This should not need to exist. If the account is linked to an account type, empty fields should exist implicitly, not explicitly in the account data. Removing a field from the account type then means that the field, if it doesn't exist in the accounts of that type, will simply cease to be altogether. If the field does exist in given accounts, then it will continue to exist as a "custom" field automatically, because it's no longer in the template. If the user wants to remove all data associated with a field that's been removed at the account type level (though I can't imagine why anyone would want to do this on an _typewide_ scale), bulk edit would be a more appropriate tool for carrying out that action. As currently planned, this feature seems to carry a high risk of data loss. > For individual accounts: > > - Add field: adds a custom field to the account, completely > independent of account types > > - Remove field: removes a field from the account (both custom and > type-specified fields can be removed) > > - Edit field: changing the name or datatype of a type-specified field > will convert the field to a custom field - ie, same as add custom > field and remove type-specified field. This all looks good, except possibly for removing a type-specified field (that should be unnecessary, but the user may want to suppress the display of a single, empty, account-type-specified field). > Common data: > > - Launchers: when launching an account, first check if an account has > a custom launcher - if so use it, otherwise use launcher from account > type if any. Changing the account type launcher won't directly affect > any of the accounts (or custom launchers), since the only change is > on the account type - any custom launchers will continue to exist as > they were. Will launchers be tied to fields? The use case I have in mind is multi-service accounts: my ISP provides E-mail (SMTP), news feeds (NNTP), a web login (HTTP), and hosting (FTP) with the same set of credentials. I'd like a field for each address, and the ability to launch the appropriate application for each one, all in the same account. Note, however, that if the common launcher info is in the account template, users may not be able to change it. This is a Bad Thing (and potentially crippling) on multi-user systems. It's just obnoxious on single-user systems. In the case where a user takes their keyring from one computer to another, an external store of launcher data is a plus (since the two systems are likely to have different software available). This feature probably needs more discussion/thought. > - Icons: icons are only stored for the account type, and cannot be > overridden by individual accounts. This is because the icon is the > primary means of identifying the account type. Only the software cares about account types. Users care about *logging in*. By extension, users care about account type only insofar as it helps them find the account they want. To that end, I think that customizable icons would be much more helpful than account-type-only icons in quickly finding the right account. In any case, if the accounts were linked based on tags you'd get account type searching for free, too. Not to mention you could retroactively apply account types, and all sorts of other nifty things. ;) > > Possible example where I could use the file field: > > - - Storage of my OpenVPN keys. > > - - Storage of my encrypted home folder key files. > > If I'm not mistaken, these would need to be stored in the file system > in order to be used by the applications. Why should we store them in > Revelation as well? > > Hm, when thinking about it, I could actually have a use for this > myself too - to store X509 certificates, certificate signing > requests, and private keys for them. ... A "file field" means "store a path" to me, not "store the complete contents of a file." Am I misunderstanding something? :) Thanks, -- Travis
signature.asc
Description: PGP signature
