Depend on SharpZipLib

[adamhathcock]

Thinking of using https://github.com/icsharpcode/SharpZipLib Instead of directly using implementations of my own (or forked earlier). SharpZipLib used to be LGPL so I never looked at it. Now it’s MIT.

This project was never about implementing the algorithms or even the archive formats but having an easy and unified interface while allowing forward-only access.

Probably relates to #470

[adamhathcock]

Probably cannot directly use nuget packages as not much is useful. Probably some code porting is required

[Svetomechc]

Why not use https://docs.microsoft.com/ru-ru/dotnet/api/system.io.compression ?

[adamhathcock]

Because I need access to a lot of the internals of archive formats and they don’t expose them. Otherwise, I’d love to.

[turbolocust]

Offering interruptible async API's would then be more difficult, because you would loose control over portions of the code. SharpZipLib does not support them yet: icsharpcode/SharpZipLib#223

[adamhathcock]

I need to put some brain power to what the proper way is to implement async for streams. Often I see that there’s nothing really to do?

[turbolocust]

A task has to be returned, that's basically all there is to do (see this link). If the operation should be cancelable, then a CancellationToken should be supported by the API. Streams in .NET usually support this. But if instantaneous cancellation is required, the algorithm that does the archiving logic should support this as well. Also, according to the link in my previous post, SharpZipLib does not support async methods in their stream classes, which is why I wouldn't consider using their library as long as this feature is missing.

[adamhathcock]

I meant more like if I use the async methods is that good enough? Would sync reuse the async code paths okay?

Not sure at the moment.

[Svetomechc]

@adamhathcock you mean sync methods actually calling async ones with .GetAwaiter().GetResult()?

[adamhathcock]

Like if I only implement the async part of Streams, does it use that path if someone uses the sync part?

I don’t want to have people use GetAwaiter().Result() or Wait() which ties up an extra thread.

[Svetomechc]

@adamhathcock that is a really good question.

[Bluscream]

that is a really good question.

which noone was ever able to answer :D

[adamhathcock]

nope

I'd probably just make everything async and let the Stream overloads (or provide them myself)

async has been around long enough