FAQ
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

Search Discussions

  • Johannes Schlüter at May 15, 2014 at 11:32 am

    On Thu, 2014-05-15 at 09:02 +0100, Lester Caine wrote:
    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
  • Lester Caine at May 15, 2014 at 11:54 am

    On 15/05/14 12:32, Johannes Schlüter wrote:
    On Thu, 2014-05-15 at 09:02 +0100, Lester Caine wrote:
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 15, '14 at 7:59a
activeMay 15, '14 at 11:54a
posts3
users2
websitephp.net

People

Translate

site design / logo © 2022 Grokbase