I see that writing an encoder/decoder is on your list of future features. I would like to switch from eAccelerator to xcache, but the encoder is a must-have feature for me. Are you open to the idea of funding development of specific features? If so, I would like to fund the development of the encoder in order to move it up on your priority list. Please let me know. Thanks.
on 15.11.2006 07:16
on 16.11.2006 01:34
Sam wrote: > I see that writing an encoder/decoder is on your list of future > features. I would like to switch from eAccelerator to xcache, but the any reason to switch ea to xcache? and not Zend Encoder? > encoder is a must-have feature for me. > > Are you open to the idea of funding development of specific features? If > so, I would like to fund the development of the encoder in order to move > it up on your priority list. let's see if i can kick the remain problems so the encoder/decoder can be fit into processor/*.m4 > > Please let me know. > > Thanks.
on 16.11.2006 07:16
moo XCache wrote: > any reason to switch ea to xcache? and not Zend Encoder? Yes. EA is buggy, especially with newer versions of PHP. And they are dropping support for the encoder with the next version, because it is unreliable with PHP 5.x. Zend Encoder is: 1) closed source 2) not free 3) not an opcache/precompiler - just a code obfuscator. To get bytecode compilation you have to purchase the expensive Zend Platform product. > let's see if i can kick the remain problems so the encoder/decoder can > be fit into processor/*.m4 Any ETA?
on 17.11.2006 09:47
Sam wrote: > moo XCache wrote: >> any reason to switch ea to xcache? and not Zend Encoder? > > Yes. EA is buggy, especially with newer versions of PHP. And they are > dropping support for the encoder with the next version, because it is > unreliable with PHP 5.x. > > Zend Encoder is: > > 1) closed source but for your information, there's a deZender that decompile precompiled files into php source. do u (and others) think it more safe to precompile the php script by a "open source project"? > 2) not free > 3) not an opcache/precompiler - just a code obfuscator. To get bytecode > compilation you have to purchase the expensive Zend Platform product. > > Any ETA? i wonder, as there's so may hacking way coded in php5.x opcode that makes it hard to check what the kind of opcode data it is. i can implement a "cache to disk" first, which is however, generate non-portable file between big/little endian, 32/64bit arch.
on 15.12.2006 17:16
moo XCache wrote: > do u (and others) think it more safe to precompile the php script by a > "open source project"? Yes. For many reasons, I cannot include closed source/proprietary technologies into our product. (End-of-life being one; we have platforms that see 20-30 years of service.) I doubt any closed-source provider will provide support that long. > > i can implement a "cache to disk" first, which is however, generate > non-portable file between big/little endian, 32/64bit arch. This would not be a problem for me. I would really like to have a pre-compiler; it would provide a bit of security and most importantly provide greater performance. I would say the encoder/decoder is #1 most important feature for me. --Yan
on 16.02.2007 02:54
> I would say the encoder/decoder is #1 most important feature for me.
Me too. Any update on where this sits on the priority list?
on 21.02.2007 11:27
Sam wrote: >> I would say the encoder/decoder is #1 most important feature for me. > > Me too. Any update on where this sits on the priority list? Me too. :-)
on 25.02.2007 12:18
I wait for some exact date or milestone for month about this feature. This is the number one reason for me for changing to xchahce.
on 03.09.2007 17:11
Bump. Has there been any change with respect to planning of this feature? I'm getting ready to deploy a large site and would love to use xcache. But we require that the php files all be pre-encoded on the server. As I said before, I would be happy to fund the development of the encoder in order to move it up on your priority list. Thanks.
on 13.09.2007 11:11
Sam wrote:
> Moo, anything new to share here?
sorry, but not yet. and btw i'll try my best but i'm not full time on
XCache
on 16.09.2007 06:10
moo XCache wrote: > sorry, but not yet. and btw i'll try my best but i'm not full time on > XCache I'm willing to pay you!!! :)
on 18.09.2007 13:49
Hi.. Just a suggestion.. BCOMPILER is probably interesting for you.. It's a spin form eA. No caching, just OPCODE serialization and de-serialization. CVS version works quite ok with PHP 5.2. The problem is that development is slow.. -Z
on 19.09.2007 21:14
I would also like to show my support for an encoder/decoder.
on 15.12.2007 15:17
Martin Hill wrote:
> I would also like to show my support for an encoder/decoder.
Me too ! ;-)
B.t.w. : XCache rocks !
on 21.12.2007 07:12
anyone want to contribute or support XCache 2.0 developing may read http://xcache.lighttpd.net/wiki/Contributing but encoder/decoder have to be after disk based caching aka cache to disk (while the only cache to memory is supported currently)
on 13.02.2008 21:29
moo XCache wrote: > anyone want to contribute or support XCache 2.0 developing may read > http://xcache.lighttpd.net/wiki/Contributing > but encoder/decoder have to be after disk based caching aka cache to > disk (while the only cache to memory is supported currently) If "cache to disk" allows us to: 1) make sure all files are cached, 2) create a tarball of the cache, 3) transfer the tarball to another machine (same OS, same endian, same 32/64 bit), 4) and then run without having source code on the other machine, then we could switch to using Xcache.
on 14.02.2008 01:34
> If "cache to disk" allows us to: > > 1) make sure all files are cached, > 2) create a tarball of the cache, > 3) transfer the tarball to another machine (same OS, same endian, same > 32/64 bit), > 4) and then run without having source code on the other machine, > > then we could switch to using Xcache. i'll try when i make some time
on 11.03.2008 14:04
Vulcan Logic Disassembler The Vulcan Logic Disassembler hooks into the Zend Engine and dumps all the opcodes (execution units) of a script. It was written as as a beginning of an encoder, but I never got the time for that. It can be used to see what is going on in the Zend Engine. http://www.derickrethans.nl/vld.php Hehe.. =)
