On Sun, 2007-02-25 at 08:15 -0500, Karoly Molnar wrote:
> There's only one question left unanswered for me. What are the hard
> coded functionalities regarding to the connection between the account
> type and the accounts. More directly the same question when an account
> type is changed what happens with an account which is based on that
> account type.

The details of this will be worked out when I implement it, but I'll
outline my plans below.

> Lets say that I create two FTP accounts and I modify the launcher on
> one, the other stays untouched. If I modify the launcher on the ftp
> account type the modified account is still going to represent the
> modified launcher. And the one which was untouched is going to use the
> new default account type launcher. Is this right?

Yes, that's right - custom launchers will be preserved when you change
the account type launcher.

> Other example what happens if I modify a field name on an account type
> that is going top be reflected on all account connected to that
> account type except the ones where that field was removed or renamed.
> Is this right?

Yep, right again.

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

> There are many other use case scenarios where I'd have question. I'd
> appreciate If you could clarify what functionalities are going to be
> hard coded for the account type change if any.

For account type changes, it would be something like this:

- Add field: also add the field to all accounts linked to the type.

- 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

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

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.

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.

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

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

> Thanks again and let me know how I can contribute,

Great :) Well, if you want to write code it's probably best if you wait
until the basic new account infrastructure is in place, as it will have
major changes to most of the codebase. But you could have a look at bugs
or features in the issue tracker and start planning how to implement

Also, there are requests for import/export of many different file
formats in the issue tracker, so if it sounds interesting you could
start by reverse-engineering some of the file formats and writing
incomplete importers (ie, load the data from the file and just print it
to screen, then implement account creation etc when the new account
system is done).

Other than that, translations are welcome. Documentation would be nice
as well, but there's probably no point until 0.5.0 is released, because
of all the UI changes it would introduce.

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