corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Request for review: branch RTC_platform
Date Thu, 01 Jan 2015 11:00:44 GMT
On Thursday, January 1, 2015, Peter Kelly <> wrote:

> > On 1 Jan 2015, at 5:20 pm, jan i < <javascript:;>> wrote:
> >
> > Hi.
> >
> > platform/src/wrapper.c
> > platform/headers/DFPlatform.h
> > core/src/lib/DFZipFile.c
> >
> > need a review before committing. We have API changes (minizip is
> isolated)
> > and before committing I would like to hear others opinion.
> >
> > I have (based on a good hint from dennis) created origin/RTC_platform
> with
> > all the changes. Feel free to make changes directly there or discuss it
> > here.
> I don’t understand the rationale behind this - DFZipFile already provided
> an abstraction layer over minizip (in the sense that this is the only file
> that used any minizip data types/functions).

the rationale is,  as discussed earlier, to isolate minizip in platform. I
looked at moving DFZipFile.c to platform, but that would mean that
DFstorage should also move which would be incorrect.

We wanted to make platform an abstraction over OS as well as zip and other
libraries, so we easier could replace them.

> > I have on purpose limited the zip API to only handle one zip file....If
> we
> > one day decide to go multithreaded (in contradiction to multi process) we
> > need to make the variabels in wrapper.c thread_local (which is easy).
> It needs to be multithreaded - UX Write already depends on this and the
> old API worked fine - in fact that’s the whole reason DFZipeFile exists.
> The minizip API already provides an handle object with which you can have
> multiple zip files open concurrently (in the same or different threads),
> and if we’re going to replicate the minizip API we should at minimum keep
> this capability.

ok I will ad that capability (it is quite easy to do).

> An example of where you might want two zip files open at the same time is
> if you’re converting from .docx to .odt. While the current implementation
> reads the whole source file into memory, an optimisation that would be very
> useful for files containing large images is to have it only read the
> contents on demands. So during a conversion you would have an input zip
> file handle and an output zip file handle. Thread-locals will not solve
> this problem.

you are right, multizip API will be available very soon.

jan i

> —
> Dr Peter M. Kelly
> <javascript:;>
> PGP key: <>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

Sent from My iPad, sorry for any misspellings.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message