New framework: KCalCore

[Volker Krause]

On Wednesday, 17 July 2019 01:51:42 CEST Aleix Pol wrote:
> On Tue, Jul 16, 2019 at 6:10 PM Volker Krause <vkrause at kde.org> wrote:
> > 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
> 
> I tend to agree. If so I'd suggest KCalendar. Following KContacts
> (which should possibly be KVCards, but we assume vcards are the one
> and only format ever for contacts).

It's not necessarily the one and only file format (and support for other file 
formats is possible in those libraries, KCalCore e.g. can read some iCal 
predecessor too), but both vcard and ical have effectively been the one 
ubiquitous data model in the past two decades for this kind of data. That IMHO 
justifies the very generic naming :)

In the earlier discussion David Jarvie raised concerns about the KCalendar 
name being misleading towards a calendar systems related library. Valid point, 
but IMHO the topic of calendar systems is more specialized (and typically an 
implementation detail of other libs), compared to the calendar conecpt 
KCalCore is referring to, so KCalendar vs KCalendarSystems would IMHO be 
acceptable.

Other views/opinions on this?

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/20190718/6678c533/attachment.sig>