> On 1 Jan 2015, at 5:20 pm, jan i <[email protected]> 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). > 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. 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. — Dr Peter M. Kelly [email protected] PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
