On Thu, 2007-02-22 at 16:39 -0500, Karoly Molnar wrote:
> When I originally wrote my question about why the account types are
> good at all I was coming for the same perspective where Trevis was
> coming. I see account types as extra stress on the source code and on
> the developers, because If you have a simple easily maintainable data
> structure the software itself is a lot simpler to create and extend
> later. In order to find the best solution I decided to put together a
> specification which includes both the data and the usability side. I'd
> like to invite all of you to add modify, comment constructively what I
> put together here.

I think most of the discussion stems from a misunderstanding of how the
new account types are meant to work. Please see my previous email for a
more detailed description of this system.

> === Definitions ===
> - - Field
> This is the smallest entity in the system, a container which holds the
> actual information what the user wants to store. There are several
> types of the field which are hard coded into the system and all of
> them have certain functionality.

So far we agree :)

> List of types:
> * Text
> Can hold one line of characters. Can copy the test to the clipboard.

Already planned, called "string".

> * Password
> Can hold one line of alphanumeric characters and able to generate text
> based on certain rules. The visibility of the content of the field is
> changeable. Can copy the password to the clipboard.

Also planned, called "secret" (as it can contain non-password data as
well, such as PIN codes).

> * Multi line text
> Can hold multiple lines of characters

Planned, called "text".

> * URL
> Can hold one line of characters which are pointing to a website. The
> format is http(s)://........... It can launch the browser to view the
> website. The browser can be set also.

Planned, but will allow URLs with any scheme, not only http(s):// (ie,
ftp:// svn+ssh:// or others).

> * Email
> Can hold one lines of characters. The format is [EMAIL PROTECTED]


> * Intelligent Launcher
> Can hold one lines of characters. The content of the field can be
> executed by the shell. The line can contain pointer to other fields.
> Example: command %user% %password%

This should not be a field, but rather a piece of metadata (in the same
way as name or tags). The launcher is not a part of the actual account
data, which is what the fields describe, and I see no benefits to
treating it as such.

> * Date
> Can hold a date and time with a date time picker tool.

Good idea - should probably have both "date" and "datetime" types.

> * File
> Can contain the name and the content of a file

I have been thinking a bit about this before. I think it might be useful
with two different types; "filepath" which is the path to a file in the
filesystem (say, an encrypted file for which you want to store the
password), and "binary" which is binary data that can be imported from a

However, I haven't come up with any use-cases for the "binary" field,
and don't know which way it would be best to display this - should we
determine the mime-type of the data and launch the application the user
has set in his prefs to open it? If so, we would need to store the file
on disk, which is a security issue - unless we require a RAM-disk for
this (I think glibc already required a RAM-disk at /dev/shm, maybe we
could use this).

> - - Tag
> This is a user defined data which can be used for labeling.


> - - Account
> This is a container which hold several fields in itself. Properties of
> an account:
>  * Name
>  * Icon
>  * Multiple tags

Also; launcher, description, and note - all of which I've had requests
from many users about, and I agree with.

> - - Collection
> This is a set of rules what defines an account. The rules can define
> the name, the icon, predefined tags, list of fields and the content of
> the fields.

As well as launcher. Not sure about predefined tags, I don't really see
the use, but I might be persuaded.

> - - Container
> This is a file which can be saved and loaded to and from the disk. The
> structure of the file is XML. It is encrypted with a single password.
> It contains:
>  * Accounts
>  * Collections


> === Operation ===
> - - Create account
> - - Create account based on a collection
> - - Delete account
> - - Duplicate account
> - - Edit properties of an account:
>  * Name
>  * Icon
>  * Tags

Agree in principle, but the two create account items will be merged.
Duplicate can be handled by standard copy/paste functionality, with
which most users are already familiar.

> - - Edit list of fields of an account:
>  * Remove field
>  * Add field
>  * Rename field
>  * Change type of field

Rename and change type can be handled by the same action, "Edit field".

> - - Edit content of fields of an account

> - - Edit list of fields of multiple accounts
>  * Remove field
>  * Add field
>  * Rename field
>  * Change type of field

This will not be necessary with my account type proposal.

> - - Edit content of fields of multiple accounts

Probably a good idea, but it will not be implemented until after 0.5.0
(there's enough work to do already, and I want to release as early as

> - - Create collection
> - - Delete collection


> - - Duplicate collection


> - - Edit properties of a collection
>  * Name of collection
>  * Icon of collection
> - - Edit rules of a collection
>  * Name of to be created account
>  * Icon of to be created account
>  * Tags
>  * Remove field
>  * Add field
>  * Rename field
>  * Change type of field


> - - Create container
> - - Load container
> - - Save container
> - - Save as container
> - - Delete container

No, the whole new/open/save file handling thing will be removed in
0.5.0. Instead, we will operate on a default database in ~/.revelation/,
but include a "Change Database" menu option to open a different
database. Deleting it can be done with any normal file editor.

> === Display ===
> - - Show accounts
> - - Filter accounts based on multiple tags. Have at least a 2 levels
> filtering.
> - - Search within the accounts


> === Other functionality ===
> - - Import and export from and to other applications
> - - Password generation based on length and character set. (avoid
> ambiguous characters)
> - - On application start reload last opened file


> - - Lock application and ask for password again after a certain amount
> of time

Yep, possibly with an option. Will also be integrated with
gnome-screensaver via DBUS to lock when screensaver goes on.

> === Back to our discussion ===
> There were two main questions during our discussion regarding to the
> account type vs template question:
> Filtering / Searching:
> With multiple tags the filtering is possible in a very flexible way.
> On one hand it can be filtered by interest let say "my mothers stuff"
> on the other hand it can be filtered by similar accounts, lets say "my
> credit cards". Combining these two options gives us a very powerful
> filtering capability.

I responded to this in another thread:

"Using tags to store the account type is the Wrong Thing to do.
First, by even implying the idea you admit that there is such a thing as
an "account type" in the real world, and if our data model does not
reflect this then that model does not correctly represent what we are
trying to describe. Also, you are now describing two different pieces of
data (account type and keywords) in the same field, which is a big no-no
in data modelling as it has all kinds of bad consequences."

> Changing easily multiple similar accounts:
> With the "Edit list of fields of multiple accounts" and the "Edit
> content of fields of multiple accounts" functionality we are able to
> change everything what we want on multiple accounts. 

Probably a good idea in any case, I've opened ticket #238 for this:


> If I compare this with the maintaining the connection between account
> and account types
> I have to say that the existing way is much less powerful and it
> depends on hard coded functionality.

No-one is advocating using the existing account type system, we are
talking about a new system.

> Lets say that we have 10 ftp
> accounts and the code of the web account type says that the icon and
> the launcher of the account type must be the same on all of the
> accounts. This way if the launcher is changed on the account type it
> is going to be reflected on the individual accounts too. Very good.
> How about if you want one account handled by a different ftp client?

The launcher on the account type is only the default launcher, it can be
overridden by a launcher on a specific account.

> How about if I change my username for all of my ftp accounts and that
> is not maintained by the ftp account type. I will end up opening all
> 10 accounts and renaming each of them.

This can be handled by bulk changing, which don't really have anything
to do with the data format. See my reply above.

> I don't have any problem with
> the account type, but I'm against any hard coded functionality,
> because today we agree to build these functionality and it turns out
> that the people wants to use it differently. If we go with the new
> model they are allowed to do whatever they want and we don't ever need
> to change the hard coded functionalities because there are none.

Again, there will be no hard coded handling of account types. The user
will be able to do whatever he wants, we just want to help him do it
instead of making him do all the work manually.

> It seems to me that with having simple arbitrary account with tags and
> bulk edit revelation would offer more functionality and freedom than
> with account types. I'm still open minded to hear your arguments and
> would love to see you modification to the above specification.

No, it would offer less functionality, have an equal degree of freedom,
and mean more work for users.

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