Having now established that phpng only currently supports MySQL and
SQLite, many of us are once again cut out of the loop. That the
structural changes require a deep understanding of the 'new engine' to
make the missing extensions available cuts out other people picking up
the baton easily, so we are stuck with a half built alternative and no
roadmap as to when it may be testable by everyone?
The 32/64 bit discussion has a great relevance to interfaces like the
database ones where these may already be supporting 64bit length
strings, and the like, so coming up with an acceptable compromise on
this is important.
I STILL see 'unicode' in this jigsaw as maintaining 32bit length strings
with a multibyte capability for those areas where in reality even a
16bit limit would be more appropriate? Can we please identify all of the
elements that need to be addressed for PHPNext, rather than pushing
votes on things which essentially combine a number of unrelated options.
PHP still has to support 32bit lengths on 32bit platforms so 64bit
strings have to co-exist with that.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Having now established that phpng only currently supports MySQL and
SQLite, many of us are once again cut out of the loop. That the
structural changes require a deep understanding of the 'new engine' to
make the missing extensions available cuts out other people picking up
the baton easily, so we are stuck with a half built alternative and no
roadmap as to when it may be testable by everyone?
Well, the changes most extensions need for ng are mostly
straight-forward, mostly mechanical and probably we can even automate
that to quite some degree (be it with some grep/sed/... foo or a clan
plugin)
But even then the actual issue remains: We don't have developers who
know how to setup all libraries and systems to test those changes. PHP,
for the most part, is driven by people who have a problem and work on
it. Looking at the history of the interbase extension it is more than 10
years since anything but mechanical changes have been made. If you
provide constructive feedback and test those mechanical changes I'm sure
somebody will assist ... but best is if you find somebody from the
firebird community who wants to work on this, I'm sure they'd be
welcomed ...
johannes
Having now established that phpng only currently supports MySQL and
SQLite, many of us are once again cut out of the loop. That the
structural changes require a deep understanding of the 'new engine' to
make the missing extensions available cuts out other people picking up
the baton easily, so we are stuck with a half built alternative and no
roadmap as to when it may be testable by everyone?
Well, the changes most extensions need for ng are mostly
straight-forward, mostly mechanical and probably we can even automate
that to quite some degree (be it with some grep/sed/... foo or a clan
plugin)But even then the actual issue remains: We don't have developers who
know how to setup all libraries and systems to test those changes. PHP,
for the most part, is driven by people who have a problem and work on
it. Looking at the history of the interbase extension it is more than 10
years since anything but mechanical changes have been made. If you
provide constructive feedback and test those mechanical changes I'm sure
somebody will assist ... but best is if you find somebody from the
firebird community who wants to work on this, I'm sure they'd be
welcomed ...
The only problems we have had with the interbase driver have been caused
by these very 'simple mechanical changes' which disabled some key parts
of the driver for several versions in the PHP5.1 days and eventually we
learnt enough to fix the problem. Hopefully Mariuz may be able to pick
this up as he has been slowly clearing the edge case bugs from the last
10 years, but there has been simply no need even to finally split off
the firebird 'view' from the interbase driver simply because everything
works. ( PDO is a different matter ;) )
But my backup to look at phpng would be postgres since that at least
will run the SQL queries that I use. It is a major blocker that testing
of a key performance area is restricted to a single database target.
Interaction between these two areas is the main bottleneck on all of my
systems so tinkering with the core engine as far as I can see does not
have as much impact on a full system. If you strip out many of the areas
that need to work isn't it obvious that things will be faster? If I drop
support for cross database working I can get a 30% performance boost.
All of this depends on your final target requirements?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk