-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First of all thanks for the clarity. After reading this and your other
email on the XML format thread I have a much better understanding of
the new system. So again, thank you.

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.

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?

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?

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?

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.

Possible example where I could use the file field:
- - Storage of my OpenVPN keys.
- - Storage of my encrypted home folder key files.

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

Erik Grinaker wrote:
> There seems to be some misunderstandings about the current plans for
> implementing accounts and account types, so here is a quick description
> to try to clear some things up.
>
> Account types specifies which fields accounts created from them will
> contain. In addition, account types contain common data for the accounts
> belonging to them, notably the icon and the launcher. They have this
> data:
>
> - id: a unique id for the type (used for file merging etc)
> - name: a name for the type (for example, "Website")
> - description: a description for the type, used for tooltips etc
> - icon: an icon for the type (common to all accounts)
> - launcher: the default launcher for the type (can be overridden)
> - fields: a set of fields for the accounts
>
> Accounts will be created based on their type, with the fields from the
> type and some metadata. They are linked to the type they were created
> from. They have this data:
>
> - id: a unique id for the account (used for file merging etc)
> - name: a name for the account
> - description: a short description
> - note: a multi-line note
> - launcher: a custom launcher (overrides default launcher)
> - tags: a set of tags, or keywords, for the account
> - fields: a set of fields for the account
>
> Revelation will come with a default set of account types, which are used
> when creating a new datafile, but any of these types can be modified or
> removed at will, and new ones can be created. There will be no
> restrictions on this. When fields are added, changed, or removed from an
> account type, corresponding changes will also be made to the accounts
> belonging to them.
>
> It is also possible to add fields to specific accounts which are not
> present in the account type, and fields from the account type can also
> be removed from individual accounts. The account type launcher can also
> be overridden by custom launcher on any individual account, but the
> account type launcher is used as a fallback of none is found on the
> account.
>
> There seems to be a conception that having account types will require
> hard-coded functionality or specific code paths for various account
> types. This is wrong, and I do not understand why one would have that
> impression. Revelation will be completely data-driven - again, any of
> the account types can be removed or modified at will, and new ones can
> be added.
>
> So, to try to get this discussion down on the ground: what specific
> functionality do you believe this data structure would prohibit?
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF4YwDOkBLd7nU8XcRAuSfAKCJFEqdMmm5pSAspnPnb2Au8NqpxgCfWEOK
hBsvvjBrFIbpyQ7D0a4q6Zs=
=LqhS
-----END PGP SIGNATURE-----


Reply via email to