Use of Boost library classes in kdecore?

[David Jarvie]

On Sunday 08 July 2007 11:18:00 Thiago Macieira wrote:
> David Jarvie wrote:
> >There are two classes in kdelibs: KSystemTimeZone, which represents time
> > zone data returned by glibc funtions, and KTzfileTimeZone, which
> > represents the full time zone data held in the system time zone
> > database. The former only gives information for recent years, but is
> > presumably faster to call than the latter, which reads and parses the
> > database files.
> >
> >But there are other forms of time zone data, notably iCalendar VTIMEZONE
> > data. This is represented in kdepimlibs/kcal by the ICalTimeZone class.
> > It contains extra data compared to the other classes. There could also
> > be a need in the future to cater for other data sources which may have
> > different information. By allowing classes to be derived, kdelibs
> > doesn't restrict the data which they can access, and of course, it
> > avoids having to change KTimeZone's API every time a new time zone data
> > source is implemented.
>
> And why can't all of these different backend implementations be completely
> internal to KTimeZone? Move them all up into kdecore and flatten the
> hierarchy: the only publicly visible class is KTimeZone.

It needs to be possible for further time zone data formats to be handled in 
the future without amending kdelibs. We can't say that we have implemented 
all the formats which will ever occur yet. And it's always possible that some 
individual application might have special data requirements and need to 
implement its own class. So it needs to be possible to derive new classes or 
create new backends, and to create extra methods to access data 
format-specific information.

> And then add a method to select the backend or the data source for those
> applications that need it.
 
-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm