New framework: KCalCore

Sat Jul 20 16:40:30 BST 2019

El dissabte, 20 de juliol de 2019, a les 12:14:09 CEST, David Faure va escriure:
> Hi everyone,
> 
> I just discussed this with Volker IRL and I found a solution to address my 
> initial concern with the name, the fact that a developer (who's new to all 
> this) seeing "Cal" might not understand this as meaning Calendar.
> At the same time, KCalendar is unclear (does it display a calendar? is it 
> about calendar systems? etc.). And we already discussed the problem with the 
> other alternatives (a new developer wouldn't understand Incidences, iCal isn't 
> the only format behind all this, etc.)
> 
> So I suggested KCalendarCore, and Volker agreed.
> 
> Unless there are strong objections, we'll go with that.

All names are bad to some degree, let's just choose one and make sure the API documentation states clearly what this is for and that should be enough.

Cheers,
  Albert

> 
> Cheers,
> David.
> 
> On jeudi 18 juillet 2019 23:24:15 CEST Dominik Haumann wrote:
> > To me this sounds as if KCal is the best choice: KCal - a library with iCal
> > support. It's short, closest to iCal, and does not clash with calendar
> > systems.
> > 
> > Greetings
> > Dominik
> > 
> > Allen Winter <winter at kde.org> schrieb am Do., 18. Juli 2019, 18:40:
> > > On Thursday, July 18, 2019 12:18:36 PM EDT Volker Krause wrote:
> > > > 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?
> > > 
> > > There was once a KCalendarSystem class.
> > > We may need to resurrect it , but I forget why.  Maybe for holidays.
> > > 
> > > I don't think KCalendar or KCalendarSystem is good.
> > > 
> > > to make an analog of KContacts you'd have to call this KIncidences.
> > > I don't hate that.  The library is really about Incidences.  A calendar
> > > is basically a collection of incidences,
> 
> 
> 