On Sun, 25 Feb 2007 22:39:12 +0900, Erik Grinaker <[EMAIL PROTECTED]>

(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

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

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? :)



Attachment: signature.asc
Description: PGP signature

Reply via email to