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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
