----- Original Message -----
From: "Ettore Perazzoli" <[EMAIL PROTECTED]>
> > so I want to make a plea for storing user data (as the addressbook)
> > in evolution in a plain format (be xml, vcard, txt, whatever),
> > so I do not need the specialized app (evolution in this case)
> > to access *my* data.
>
> Unfortunately it is not that easy.
>
> Changing to a plaintext format without losing in performance or eating
> more memory that we currently do would require a considerable amount of
> non-trivial hacking due to the way the Wombat currently works... Also,
> we don't want to change the addressbook format again at this point; we
> are going to hit feature-freeze soon, and it is definitely too late to
> make such a big change.
well, then please consider it for 2.0
anyway, if you stick with libdb, sooner or later you will have to change
the format...
> Anyway, I think the current situation is good enough. Evolution just
> uses the db3 format for the addressbook, and since it statically links
> with a specific version of libdb, upgrades of libdb on the user's system
> won't cause damage to the contacts. Also, it is possible to migrate
> from db1.85 or db2 contacts easily (in the latter case, it's even done
> automatically on start-up).
I don't think the current situation is good enough at long term,
the addresbook should be valuable data without evolution,
think it as a problem similar to .doc without M$ word
(yes a .doc can be accessible with other soft, but it is unnecesarely
hard)
because a binary format *depend* on the implementation,
otherwise a specification (like vcard) depend on a format,
implementations can vary greately...
yes, the temptation for a binary format is too big when you want
the soft out there quickly and fast, but think of interoperability
and accesibility, this is why all standards of W3C are plaintext...
and evolution is in a position where it can define a de facto
standard for the addressbook, but not with the current binary format.
for example if evolution define a vcard format for the addressbook,
I can easily see some soft like mutt, pine, balsa, spruce, etc.
bringing support for the evo addressbook...
interoperability and accesibility, that are the keys...
(sure, is not that easy)
regards,
/sergio
ps: and ideally, the addressbook should *completely* separated from
evolution; sure, for 2.0
_______________________________________________
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/evolution-hackers
