Hm, sorry about the late reply, been busy with some other stuff lately.

On Sun, 2007-02-25 at 10:10 -0800, Travis Snoozy wrote:
> On Sun, 25 Feb 2007 22:39:12 +0900, Erik Grinaker <[EMAIL PROTECTED]>
> wrote:
> > > 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.

Well, the account types will be stored in the Revelation account
database along with the accounts. Quite simply because they are an
essential part of the data (they define the data types and names for
account fields, for example). So these are really non-issues, as well as
most of the other points you mention below.

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

Converting fields isn't really a problem, data types are "soft" and are
always stored as strings. They are basically used to determine
appropriate display and edit widgets for the fields, but they will
handle unexpected values (ie text in a number field) just fine.

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

Yeah, it's a good point and one worth considering.

Revelation will probably have the fields explicitly, even if empty, as
it's easier to program that way. But this is just an implementation
detail, and won't have any effect on the user at all.

As for converting to custom fields - I feel like it should be possible
for the user to at least choose if he wants to delete the field in all
accounts, or convert to custom wherever it is set. But it should default
to use custom fields, to avoid accidental 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.

Well, there will be 1 launcher per account type, which can be overridden
with 1 custom launcher on any given account.

As for what you're describing, I'm not sure how we would be able to do
this in a good way UI-wise, or even conceptually. It also seems like
it's a bit overkill for Revelation - I don't want Revelation to be an
overly complex application which can handle all kinds of special cases
and weird setups, as this would definitely make it alot harder to use,
but rather one that handles 95% of what people need in a simple and
straightforward manner.

In this case I think the best solution would be to create separate
accounts for all the services, which could still be easily updated with
bulk editing.

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

Not an issue, as account types are stored in the account database.

However, as for launcher configuration, there are both advantages and
disadvantages to storing it with the account types. I'll send a separate
email on this.

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

I'm not entirely opposed to allowing custom icons on accounts. However,
as the icon is the primary way to identify account types in the list, it
might be a source of confusion.

I'll include it if there is any demand for it, so speak up now if you
think this would be useful.

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

We're considering doing both. A path is useful if you have an encrypted
file on disk, but storing it in-file might be useful for X509
certificates and such.

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

Reply via email to