New framework: KCalCore

[Volker Krause]

On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote:
> On Fri, Jul 12, 2019 at 9:03 PM Allen Winter <winter at kde.org> wrote:
> > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote:
> > > With the 19.08 release approaching (and thus the deadline for
> > > incompatible
> > > changes if we go ahead with this plan), I'd like to raise this again for
> > > getting to a decision :)
> > > 
> > > Summary of what happened in the past weeks:
> > > - the Person/Attendee slicing issue was fixed by making both independent
> > > types - several "leaf" types were turned into implicitly shared value
> > > types rather than being used heap-allocated inside shared pointers
> > > - the dependency on the Akonadi supertrait.h header file was removed
> > > - the virtual_hook usage in the incidence de/serialization code was
> > > replaced by new virtual methods
> > > 
> > > Unless I missed something, the remaining unaddressed feedback is down
> > > to:
> > > - Rename KCalCore to something else. I'm ok with executing the rename,
> > > but
> > > somebody needs to tell me the new name :)
> > 
> > I don't remember the reason for changing the name.
> > I vote for not changing the name. KCalCore is as good as any, imo
> > 
> > > - Alexander P's fundamental objections to the current KCalCore API
> > > 
> > > How do we proceed?
> > > 
> > > Thanks,
> > > Volker
> > > 
> > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote:
> > > > Hi,
> > > > 
> > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5.
> > > > 
> > > > KCalCore is an implementation of the iCalendar standard based on
> > > > libical,
> > > > covering the data model, input/output and the rather complex
> > > > recurrence
> > > > algorithms defined in that standard. It's used outside of KDE PIM as
> > > > well,
> > > > e.g. by Zanshin or the Plasma Mobile calendar app.
> > > > 
> > > > KCalCore depends on Qt and libical only, making it a Tier 1 functional
> > > > framework.
> > > > 
> > > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so
> > > > it's well prepared for complying with the API and ABI guarantees.
> > > > 
> > > > I'd suggest the same timeline as proposed for KContacts [1]. During
> > > > the PIM
> > > > sprint we did a number of fixes and cleanups as part of the review for
> > > > KF5
> > > > that make 19.08 the earliest release after which we can switch as
> > > > well, so
> > > > we are looking at a switch in Sep/Oct this year.
> 
> If you don't remember, just scroll up a bit. :P
> 
> I went through the thread and that's what we said:
> - It's a framework to understand the ical format, this is not conveyed
> by the current name
> - The Core postfix doesn't add anything and we are already using it
> for differentiating different framework targets (e.g. KF5::ConfigCore
> and KF5::ConfigGui)

"Core" had exactly the same meaning here when the widget parts were split out 
during the Nokia times. Less relevant today probably.

> I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents,
> KCalendarIncidences being suggested. It's not going to be me who
> chooses one though. 

If those are the options I'd vote for KCal or KCalendar, KiCal is too close to 
KiCad IMHO, and the rest is just unnecessarily long. Anyway, let's please have 
a quick decision on this, it's going to be a large change, so I'd like to get 
this in ASAP.

Thanks,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190716/d7ce7ebe/attachment.sig>