Sorry for the late reply.
Thomas Dickey wrote in
<zlwrndxgc21di...@prl-debianold-64.jexium-island.net>:
|On Sun, Jun 02, 2024 at 01:18:28AM +0200, Steffen Nurpmeso wrote:
|> Thomas Dickey wrote in
|> <zluz447780sh4...@prl-debianold-64.jexium-island.net>:
|>|On Sat, Jun 01, 2024 at 07:59:07PM +0200, Steffen Nurpmeso wrote:
|>|> Thomas Dickey wrote in
|>|> <zlpf6rz52lw3a...@prl-debianold-64.jexium-island.net>:
...
|>|> the zstd that is more and more used in the open source software
|>|> world, for package formats etc, and supported by webservers, too
|>|> (ie the wonderful lighttpd i use since 1.4.59 in 2021).
|>|
|>|actually - for websites so far, this seems to be used only by facebook/e\
|>|tc.
...
|>|But since I'm not aware of any useful websites relying upon zstd,
|>|I put it off for "soon" (patches will be duly considered).
|>|It also would help to see websites using the feature.
|>
|> I now looked around a bit, and found
|>
|> https://bugzilla.mozilla.org/show_bug.cgi?id=1301878#c62
...
|sure - that tells us that chrome and firefox support the feature.
|But I don't see any mention of websites using the feature.
I am not actively looking which content-types are announced by
webservers, nor have i an idea of how browsers select which of the
announced compression formats they use.
It seems my linux distribution does not use zstd for nginx nor
apache, shall this be possible at all.. I have it for the
lighttpd port since 2021-02, then as an "official contrib" port.
...
|>|> Would you be interested in adding support for that?
|>|> If i write a patch?
|>|
|>|sure - there's enough in Lynx now for gzip and brotli that the patter \
|
|s/patter/pattern/
|
|>|should
|>|be easy to follow.
|>
|> Yes i had that same impression; 'never have used it on programming
|> level, but only looked a month ago (plzip related) and found
|> unfortunately obsoleted user-passes-buffer interface variants, if
|> i recall correctly.
|
|for instance
|
|ZSTD_DEPRECATED("Replaced by ZSTD_getFrameContentSize")
|ZSTDLIB_API
|unsigned long long ZSTD_getDecompressedSize(const void* src, size_t \
|srcSize);
|
|ZSTDLIB_API size_t ZSTD_decompress( void* dst, size_t dstCapacity,
| const void* src, size_t compressedSize);
|
|(like brotli, its developers weren't very interested in portability)
Ah, oh, i was more about the "Buffer-less streaming
(de)?compression functions" at the end of the header.
But the above sounds good.
(It was my problem with lzlib, he makes i think three allocations
that "could very well" be driven by user-provided buffer(s), but he
thought it was about malloc replacement hooks, and pointed to some
glibc "oh-no let's get rid of alloc hookability" commit, which is
of course expensive on per-object level (they talk security
though), but me just wanted to get rid of those allocations
altogether. Anyhow.)
...
--End of <zlwrndxgc21di...@prl-debianold-64.jexium-island.net>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
