[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Re: [Kitchensync] Agenda and what is really important.
From:       Amir Tal <tal () whatsup ! org ! il>
Date:       2004-02-12 18:13:16
Message-ID: 200402121313.16753.tal () whatsup ! org ! il
[Download RAW message or body]

On Thursday 12 February 2004 18:56, Cornelius Schumacher wrote:

as far as i could see, kitchensync was NOT included in the RPM's provided for 
suse (kde 3.2).
kontact was installed as a part of the kde-pim package. 
where do i get Kitchensync from ?

thanks,
tal.


> (Moving the KitchenSync development discussion to kde-pim, so that all
> can participate)
>
> On Wednesday 11 February 2004 11:59, Holger Freyther wrote:
> > 1.) introduce groups so that MetaData of Local matches the state of
> > Remote
>
> Could you please elaborate. There is no difference between local and
> remote, that's all just konnectors. If you mean that when saving and
> using syncing log information it has to be considered which Konnectors
> were synced with each other, that's of course true.
>
> > 2.) clarify and maybe extend the AttributeMap. This is more
> > than needed because you simply can't say that every device supports
> > every field and that a field is empty on purpose( was deleted by user
> > action or is simply not supported ). Also this structure needs to be
> > updatet to support more attributes ( fine grained ). And maybe even
> > the custom-> entries of KABC and such. So we will have one QBitArray
> > per Syncee with defaulting to support everything and maybe a
> > QStringLIst for custom entries for the AddressBookSyncee
>
> Hardcoding the fields in the Syncee classes is way too inflexible and
> gives horribly ugly code. Either we find a solution which doesn't
> require this or we maybe have to go away from the idea that the Syncees
> use native classes for storing data like Calendar or AddressBook, but
> go to a more abstract way of passing around the syncing information,
> e.g. having sets of QVariant objects or something like that. I think
> the requirement has to be that the Syncee interface doesn't have to be
> changed if fields are added/removed/changed for a certain datatype. So
> e.g. the addressbook syncee interface shouldn't be affected by addition
> of support for syncing freebusy urls.
>
> > 3.) Cornelius remove your CalendarLocal Syncee because it does not
> > implement the AttributeMap, Doesn't differentiate between todos and
> > events ( needed for evolution ), maybe does saving in a not so clever
> > way( multisync saves per record for debug )
>
> For the attribute map see above.
>
> We currently have a duplication of some code. You duplicated the syncing
> algorithm from libksync in the kitchensync ui twice and then duplicated
> the calendarsyncee from libksync syncee by your incidence template
> based syncees and adapted them to your syncing algorithm engine. We
> should consolidate this and come back to a single syncing algorithm and
> make the syncees all fit to that.
>
> I'm currently looking at making kdepim/ksync/lib obsolete by moving the
> rest of the functionality to kdepim/kitchensync/libksync. Thois will
> already help a bit.
>
> > 4.)The reason I had ManParts for ABook and Cal was that both libkcal
> > and kabc always changed behaviour on when the modified date is
> > actually written. CalendarLocal should do it the old ABook way
> > because that would work with both libraries.
>
> Why does it matter, when the data is written? The syncing is supposed to
> happen in memory and how the Konnectors actually write the data
> shouldn't matter for anything outside the Konnector.
>
> > 5.) make it impossible to delete a Konnector for the API user except
> > over a 'Controler' ( KRES::ResourceManager or who would that be )
>
> Nice to have, but not that important I think.
>
> > 6.) Move the SyncAlgorithm from the GUI to libkitchensync
>
> And merge it with the sync algorithm which already is in libksync (I
> suppose you mean that by libkitchensync)
>
> > 7.) Make thinking threaded so that backends don't timeout their
> > sockets ( some code is there )
>
> I haven't looked into that at all.
>
> > 8.) Have a better resolve gui and maybe even more fine grained.
>
> That's also not the highest priority for me. We can always improve that
> later when the basic syncing really works.
>
> > 9.) Implement Filters in the GUI and add a state hidden to each
> > SyncEntry. This would indicate that the records was hidden by a
> > filter and a Konnector can decide for itself if it wants to write it
> > back. This could be useful to only sync a range of days or a category
> > to a device.
>
> Good point.
>
> > 10.) check that collecting of metadata is correct in the Local
> > Konnector
>
> Writing meta data is another area where we have duplicated code. The
> code from libksync writes logs which are used to determine how
> information was synced which gives additional information about how
> entries have changed.
>
> > 11.) Add Models to the Groups. So you could have One Way
> > Push. One Konnector is simply writing its data to the others (
> > upload). Pull All would download from one Konnector to all. Plain
> > Copy would copy from all sides and then also the Full MetaSyncing
> > with Meta Data.
>
> Either we do that by adding options to the SyncerPart or we add a new
> Part for one-way sync.
>
> > 12.) the move to KConfigXT and KCM Dialogs ( haven't actually looked
> > into it ). And a wizzard to set it up
>
> Yes.
>
> > 13.) install the Splash Screen at the right location. ("Is Unix ready
> > for syncing" made from the Old KDE1 logo )
>
> Why do we need a splash screen at all. KitchenSync doesn't take very
> long to start up.

-- 
===================================
Amir Tal,Founder
Whatsup, Hebrew Linux Portal
http://www.whatsup.org.il
tal@whatsup.org.il
icq : 15748705,cell : 646-296-3835.
===================================
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]