New framework: KCalCore

[Alexander Potashev]

вт, 9 апр. 2019 г. в 20:10, Volker Krause <vkrause at kde.org>:
>
> On Sunday, 7 April 2019 16:24:13 CEST Alexander Potashev wrote:
> > вс, 7 апр. 2019 г. в 15:45, Volker Krause <vkrause at kde.org>:
> > > 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.
> >
> > Hi Volker,
> >
> > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO
> > support on the way from KDELibs4 to KF 5.0.
> >
> > Of course I can subclass ICalFormat, but the FileStorage<->ICalFormat
> > relation looks weird to me: ICalFormat::save() is the method that
> > actually writes file to disk, while class name "ICalFormat" suggests
> > that it should only be concerned about iCal contents, not the I/O.
> >
> > May be CalFormat should only implement marshal/unmarshal methods, then
> > actual r/w from disk can be done in FileStorage. Otherwise, for me to
> > add KIO support right now I need to subclass ICalFormat rather than
> > FileStorage which is weird.
>
> Right. IMHO the entire file handling code should probably not be in there in
> the first place. That is, the CalStorage class hierarchy and the file I/O
> methods from the CalFormat hierachy (streaming to/from QIODevice rather than
> working with full QByteArray serialization might however make sense there).
>
> This is also why KIO support was a very bad idea in there, the KCalCore API is
> synchronous (predating KIO), while KIO is asynchronous, and so is likely any
> other persistence backend one might want to use.
>
> Looking at lxr.kde.org I'm however reluctant to remove any of this now though,
> this is still too widely used.

Hi Volker,

Thanks for your thoughts!

Since David suggested renaming KCalCore to something else, how about we instead
 1. Redesign the API (e.g. drop file handling, etc) and call it e.g.
KCal, get it into KF5,
 2. Keep releasing KCalCore as part of KDEPIM and may be port it to
KF5::KCal as backend to reduce codebase,
 3. Deprecate KCalCore and gradually port everything to the new clean KF5::KCal?
...
 4. PROFIT: nobody's code is hurt since the legacy KCalCore API is
still available.

-- 
Alexander Potashev