--===============1337093419==
Content-type: multipart/signed; boundary=nextPart1490003.0GpWrybDlP;
 protocol="application/pgp-signature"; micalg=pgp-sha1
Content-transfer-encoding: 7bit

--nextPart1490003.0GpWrybDlP
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Saturday 09 January 2010, Ecaroh wrote:
> Am Freitag 08 Januar 2010 schrieb Ingo Kl=C3=B6cker:
> > This means that it will still be possible to simply copy the flat
> > text files, but you will lose some information like tags.
>=20
> Assuming and trusting that this is true (i simply do not know it)
>  there is only one answer: If I have to care for something like tags
>  I will never be sure what to care too next release - and then:
>  surprise, surprise!!
>=20
> To come back to the Palm, categories (Tags) are not synching with
> Kpilot. You have to self care that you create necessary entries by
>  hand on both (or three if you have a pc and i.e. a notebook)
>  devices. This is not what i call usabilty.
>=20
> It's more like backup: If you have certain things that are not
>  included by default, it will fail. This is the reason for a simple
>  rule: include all (in case of backups) and exclude only specific
>  items.

At the KDE PIM meeting at Osnabr=C3=BCck which is taking place this weekend=
=20
we talked a bit about synchronisation. At the moment we do not have a=20
solution for this. There are two possible candidates for backends to use=20
for synching: syncEvolution and OpenSync. It is still undecided which=20
direction we will go. In any case, I doubt that our solution will=20
include support for the (obsolete) Palm devices.


> And I stay with the old unix philosophy:
>=20
>  - KISS (Keep IT simple and stupid)
>=20
> Sometime it seems to me that KDE is on the way of making a new
>  Kindows. And maybe some expert here can explain me what efforts i
>  have from database files for that purpose. I do not know it but the
>  new concepts are breaking a very old unix philosophy. And you have
>  to have damn good arguments to change that. Moreover, you need
>  approbiate tools to deal with databases. For years a text editor was
>  sufficient. What noteable effort is it worth to change from text to
>  database??

You are getting it wrong. We are not switching from text to database. As=20
I wrote above the storage will stay text-based. What will change is that=20
we replace our proprietary index files by a database. This is fully in=20
line with the Unix philosophy because we dump our home-brewed index=20
files in favor of a database which does the job much better. The=20
database will provide us with much more functionality which we had to=20
implement ourselves (less efficient and more buggy) in the past.


Regards,
Ingo

--nextPart1490003.0GpWrybDlP
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEABECAAYFAktJIMIACgkQGnR+RTDgudj32ACfeQVOTi+mGV9ooqGmyjqrLiPg
opwAnjWfc7oQRwkHTAN8doWTGIXuIohY
=Pes7
-----END PGP SIGNATURE-----

--nextPart1490003.0GpWrybDlP--

--===============1337093419==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KDE PIM users mailing list
kdepim-users@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users

--===============1337093419==--