Hi,
While working on the windows ports, I asked Sara about the mhash
status in regard of the new shiny ext/hash. The plan is to remove
ext/hash completely and emulate it in ext/hash to keep the BC. It
could even a configuration flag if one likes to be sure to clean his
code to use only the hash APIs.
As I would love to do it myself, I sadly don't have the time to do any
time soon. It would rock if someone could take the hand on it and send
a patch to us. I can help for any windows issue if any (that's what I
focus on these days).
Cheers,
Pierre
Hi Pierre,
Am Montag, den 02.06.2008, 01:02 +0200 schrieb Pierre Joye:
[...]
While working on the windows ports, I asked Sara about the mhash
status in regard of the new shiny ext/hash. The plan is to remove
ext/hash completely and emulate it in ext/hash to keep the BC. It
^^^^^^^^
You mean ext/mhash, right?
cu, Lars
Hi Pierre,
Am Montag, den 02.06.2008, 01:02 +0200 schrieb Pierre Joye:
[...]While working on the windows ports, I asked Sara about the mhash
status in regard of the new shiny ext/hash. The plan is to remove
ext/hash completely and emulate it in ext/hash to keep the BC. It
^^^^^^^^
You mean ext/mhash, right?
Yes, sorry for the confusion :)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
While working on the windows ports, I asked Sara about the mhash
status in regard of the new shiny ext/hash. The plan is to remove
ext/hash completely and emulate it in ext/hash to keep the BC. It
could even a configuration flag if one likes to be sure to clean his
code to use only the hash APIs.
The mhash extension features some more versions of some algorithms:
http://mhash.sourceforge.net/ But why bother changing it? I've not heard
of any issues about ext/mhash.
regards,
Derick
While working on the windows ports, I asked Sara about the mhash
status in regard of the new shiny ext/hash. The plan is to remove
ext/hash completely and emulate it in ext/hash to keep the BC. It
could even a configuration flag if one likes to be sure to clean his
code to use only the hash APIs.The mhash extension features some more versions of some algorithms:
http://mhash.sourceforge.net/ But why bother changing it?
Which algo(s) (or algo version) is not supported by ext/hash? I did
not spot one after a quick read.
I've not heard of any issues about ext/mhash.
My main reasons would be to do not have to maintain ext/mhash and the
libmhash Windows port.
Cheers,
Pierre Joye wrote:
While working on the windows ports, I asked Sara about the mhash
status in regard of the new shiny ext/hash. The plan is to remove
ext/hash completely and emulate it in ext/hash to keep the BC. It
could even a configuration flag if one likes to be sure to clean his
code to use only the hash APIs.
The mhash extension features some more versions of some algorithms:
http://mhash.sourceforge.net/ But why bother changing it?Which algo(s) (or algo version) is not supported by ext/hash? I did
not spot one after a quick read.
sha192 and sha224
snefru128
md2
I've not heard of any issues about ext/mhash.
My main reasons would be to do not have to maintain ext/mhash and the
libmhash Windows port.Cheers,
I'm happy to see us removing a dependency, especially if it makes thigns
easier to build on Windows.
Scott
Pierre Joye wrote:
While working on the windows ports, I asked Sara about the mhash
status in regard of the new shiny ext/hash. The plan is to remove
ext/hash completely and emulate it in ext/hash to keep the BC. It
could even a configuration flag if one likes to be sure to clean his
code to use only the hash APIs.The mhash extension features some more versions of some algorithms:
http://mhash.sourceforge.net/ But why bother changing it?Which algo(s) (or algo version) is not supported by ext/hash? I did
not spot one after a quick read.sha192 and sha224
snefru128
md2I've not heard of any issues about ext/mhash.
My main reasons would be to do not have to maintain ext/mhash and the
libmhash Windows port.Cheers,
I'm happy to see us removing a dependency, especially if it makes thigns
easier to build on Windows.
In case someone likes to do it, Scott has volunteered and has already
added some of the missing algo in hash. He will also add the BC layer.
Cheers,
Pierre
Pierre Joye wrote:
Pierre Joye wrote:
While working on the windows ports, I asked Sara about the mhash
status in regard of the new shiny ext/hash. The plan is to remove
ext/hash completely and emulate it in ext/hash to keep the BC. It
could even a configuration flag if one likes to be sure to clean his
code to use only the hash APIs.
The mhash extension features some more versions of some algorithms:
http://mhash.sourceforge.net/ But why bother changing it?
Which algo(s) (or algo version) is not supported by ext/hash? I did
not spot one after a quick read.sha192 and sha224
snefru128
md2I've not heard of any issues about ext/mhash.
My main reasons would be to do not have to maintain ext/mhash and the
libmhash Windows port.Cheers,
I'm happy to see us removing a dependency, especially if it makes thigns
easier to build on Windows.In case someone likes to do it, Scott has volunteered and has already
added some of the missing algo in hash. He will also add the BC layer.
Appears that sha192 isn't supported by mhash and it looks like a typo in
their documentation.
So the only one that needs added in snerfru 128 and perhaps changing the
current hash algorith of snefru to snefru256 and adding an alias.
Scott
Pierre Joye wrote:
Pierre Joye wrote:
While working on the windows ports, I asked Sara about the mhash
status in regard of the new shiny ext/hash. The plan is to remove
ext/hash completely and emulate it in ext/hash to keep the BC. It
could even a configuration flag if one likes to be sure to clean his
code to use only the hash APIs.
The mhash extension features some more versions of some algorithms:
http://mhash.sourceforge.net/ But why bother changing it?
Which algo(s) (or algo version) is not supported by ext/hash? I did
not spot one after a quick read.sha192 and sha224
snefru128
md2I've not heard of any issues about ext/mhash.
My main reasons would be to do not have to maintain ext/mhash and the
libmhash Windows port.Cheers,
I'm happy to see us removing a dependency, especially if it makes thigns
easier to build on Windows.In case someone likes to do it, Scott has volunteered and has already
added some of the missing algo in hash. He will also add the BC layer.Cheers,
ext/mhash now wraps around ext/hash in 5.3
I'd like to recommend we add a E_DEPRECATED to anything mhash_* related
and drop the extension for 6?
I'll add the BC layer tomorrow to 6.0 regardless.
Scott
Pierre Joye wrote:
Pierre Joye wrote:
While working on the windows ports, I asked Sara about the mhash
status in regard of the new shiny ext/hash. The plan is to remove
ext/hash completely and emulate it in ext/hash to keep the BC. It
could even a configuration flag if one likes to be sure to clean his
code to use only the hash APIs.
The mhash extension features some more versions of some algorithms:
http://mhash.sourceforge.net/ But why bother changing it?
Which algo(s) (or algo version) is not supported by ext/hash? I did
not spot one after a quick read.sha192 and sha224
snefru128
md2I've not heard of any issues about ext/mhash.
My main reasons would be to do not have to maintain ext/mhash and the
libmhash Windows port.Cheers,
I'm happy to see us removing a dependency, especially if it makes thigns
easier to build on Windows.In case someone likes to do it, Scott has volunteered and has already
added some of the missing algo in hash. He will also add the BC layer.ext/mhash now wraps around ext/hash in 5.3
I'd like to recommend we add a
E_DEPRECATEDto anything mhash_* related and
drop the extension for 6?
Why? The idea of this was not to get rid of mhash, it was to prevent the
dependency on a library. I don't think we should just start getting rid
of mhash.
regards,
Derick
Derick Rethans escribió:
I've not heard
of any issues about ext/mhash.
libmhash is no longer under development see
http://sourceforge.net/projects/mhash/
I guess that is enough reason to start thinking about a compatible
replacement..
--
"Progress is possible only if we train ourselves to think about programs
without thinking of them as pieces of executable code.” - Edsger W.
Dijkstra
Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research & Development
http://www.opensuse.org/