New framework: KCalCore

[Volker Krause]

On Sunday, 14 April 2019 20:30:07 CEST Alexander Potashev wrote:
> вт, 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.

That's essentially rejecting the move of KCalCore to KF5, which is a perfectly 
valid outcome of this discussion of course. If that's going to be the 
consensus it would be good to know that sooner rather than later though, to 
not waste any time on this.

Regards,
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/20190417/e8eb68bc/attachment.sig>