Andreas Muegge wrote:
the implementation of encryption is something I would like to see
Ok, thanks for letting me know (surprising: just two responses so far).
I am not sure about compression. If we talk about normal strings I
guess
you must try it out. Decompression is usually rather fast and
I can see that both would be interesting for my application.
Just as a thought, would the lzo algorithm be better than using zlib? It has
a far smaller footprint than zlib and is _really_ fast.
Cheers
Angus
___
metakit mailing list - [EMAIL
Dont remember if I expressed my opinion already:
* Compression: useful for large data, e.g. binary and string, less useful
for other types.
* Encryption: very useful.
* Combination of the two: not sure where I'd use it.
--JYL
Andreas Muegge wrote:
the implementation of encryption is
I am using compression already. Python properties combined with sting
encode('zlib') handle it transparently to the user.
Niki Spahiev
___
metakit mailing list - [EMAIL PROTECTED]
http://www.equi4.com/mailman/listinfo/metakit
I suppose that this falls along the lines of I'll wait to see the
implementation (TM). Since these are non-invasive changes to metakit,
I'm always happy to see useful features.
Here are my current comments with the proposed compression strategy: It
seems that using the in-memory
Jean-Claude Wippler wrote:
Two options not implemented in MK 2.4.9.2, are compression and
encryption.
compression sounds good
encryption done right sounds good too, but if i understand correctly it
is only thought for the file stored, not an in memory encryption so data
could end up unecrypted
