Any plan for a Zlib API ?
Why wouldn't you just fix this at the HTTP level with Content-Transfer-Encoding negotiation of some sort?
Out of curiosity, what are you sending to the server that that requires additional compression? Remember that zlib is not useful on PNG, JPEG, etc content.
any sort of real time sharing editing/documentation document even to go (3G)
plus I want to shrink those bloody 50Mb of Web SQL or 5Mb of localStorage limit ... 5Mb ain't nothing for data, we all know that, neither are 50, while native apps, talking about mobile, get as much as they want with a simple notice: this app gonna use your memory/sd/disk space
Still talking about mobile, these libraries are a complete no-go for CPU cost
Finally, if I have a gzipped file I want to work on it and keep it small I'd like to choose it via an input, decode it, work on it, and create the download with data:text/gzip to save it back
There are attempts since ages about compressing strings in plain JavaScript, I don't see why this is not in yet 'cause I don't see any reason to do not make it happen, only limits for slower CPUs and developers solutions/imagination
I hope I answered your question
br
just an UP for this topic ... anyone with other thoughts ?
Would work great with regard to the HTML 5 File API and have a reliable means to present an archives contents to users, or otherwise manipulate File data IMO... I don't want to scupper the intent, but maybe this is orthogonal to the spec.
David Foley | Senior Software Architect
+353 87 667 4504 Skype: david.d.foley
it's great to have other developers with me but I wonder if anyone would be so kind to bring this at next TC39 meeting too,
Andrea Giammarchi wrote:
it's great to have other developers with me but I wonder if anyone would be so kind to bring this at next TC39 meeting too, thanks
I'll see what I can do. I agree that app-level compression makes sense given both bandwidth x latency network constraints, and local storage constraints.
Thanks Brendan, I have also noticed node.js 0.6+ implemented a Zlib native module nodejs.org/docs/v0.6.0/api/zlib.html
Pipe oriented objects a part, the concept of having callbacks to eventually put the task in the background is not that bad too
I still think convenience Methods nodejs.org/docs/v0.6.0/api/zlib.html#convenience_Methods
are not truly the best option for a cross platform ES API ( i.e. no way to configure them if not via create() ) but it should not be hard to define an object option for the encode procedure ... something to think about but at least an effort to bring it in would be more than appreciated, thanks.
br
it's quite common to send a consistent amount of data in certain applications and the FORM does not scale here while an Ajax POST or an upload via binary gripped data would be handy.
It would also be handy to store a bit more data in localStorage, Web SQL ( for those that won't drop it ) and/or IndexDB unless this is not provided transparently for the user but being a NO-SQL project I am not sure how much performances would be affected in latter case ( strings only, not numbers or fields used as indexes )
I find quite weird in 2012 people have to write deflate, gif, zip, or libs like this in plain JS since:
To keep things easy I wonder if such API would make sense at least for most common/fast compressors such gzip and deflate
global Gz { GZIP: 2, // constant/enum value DEFLATE: 4, // constant/enum value encode: function ( input:String [, level:Short(-1,9)=-1 [, encoding:Enum=Gz.GZIP] ]):BinaryString { }, decode: function ( input:BinaryString [, length:UInt32=input.length] ):String { } }
Zip would be a great nice have too but right now I'd like to understand your take on this topic as simple as it right now, thanks.
Best
it's quite common to send a consistent amount of data in certain applications and the FORM does not scale here while an Ajax POST or an upload via binary gripped data would be handy. It would also be handy to store a bit more data in localStorage, Web SQL ( for those that won't drop it ) and/or IndexDB unless this is not provided transparently for the user but being a NO-SQL project I am not sure how much performances would be affected in latter case ( strings only, not numbers or fields used as indexes ) I find quite weird in 2012 people have to write deflate, gif, zip, or libs like this in plain JS since: 1. every browser *has* a native Zlib like parser inside, no request would be automagically retrieved with Accept-Encoding: deflate,gzip and others 2. every server side engine has easy access to Zlib like functions ( namespace or system utils ) 3. every platform has an Open Source Zlib like library included, the effort should not be much at all 4. File API and File access may require inflate/gunzip procedure or others, no way to do it easily/fast via JS 5. Blob makes partial sense without binary compressed data 6. all other use cases where compressed data may be handy for both encode/decode procedure ( WebSockets, Recorded Audio / Camera data if the format is lossless, etc ) To keep things easy I wonder if such API would make sense at least for most common/fast compressors such gzip and deflate global Gz { GZIP: 2, // constant/enum value DEFLATE: 4, // constant/enum value encode: function ( input:String [, level:Short(-1,9)=-1 [, encoding:Enum=Gz.GZIP] ]):BinaryString { }, decode: function ( input:BinaryString [, length:UInt32=input.length] ):String { } } Zip would be a great nice have too but right now I'd like to understand your take on this topic as simple as it right now, thanks. Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120131/be55db45/attachment.html>