Re: [pcre-dev] New API for PCRE

Top Page
Delete this message
Author: Graycode
Date:  
To: pcre-dev
Subject: Re: [pcre-dev] New API for PCRE
On Fri, 7 Jun 2013, <ph10@???> wrote:

> 1. Release an entirely new library (let's call it NPCRE for now). This would be
>    completely separate from the existing library. Once the new library was
>    released, the old library would not be enhanced, and only security-critical
>    bugs would be fixed.

>
> 2. Release a library that somehow supports both APIs, probably with some kind
>    of "wrapper" that converts the old API to the new one. This should be
>    possible at least for the most common uses of PCRE, but it may not be
>    possible to implement an absolutely complete mapping.



Thanks for asking what we think! I'd like to consider having two
libraries if possible. One would be NPCRE with its new API.

The other would be for a compatible old API, I'll call it "OPCRE".
OPCRE would be only a wrapper that links to NPCRE. As in option #2
above, OPCRE need not implement a complete mapping. OPCRE should have
consideration for the POSIX API wrapper as well. Perhaps the existing
C++ wrapper is in OPCRE too.

I see OPCRE as a project which uses NPCRE but is not a part of NPCRE.
Building NPCRE does not include or reference any of OPCRE. Downloading
OPCRE can be optional, and building it requires already having built
NPCRE for linkage.

An application may use either OPCRE or NPCRE, but not both.  The header
#define values such as PCRE_CASELESS can be very different for OPCRE
than for NPCRE.  Similarly, the header for OPCRE might:
    #define pcre_compile(a,b,c,d,e) opcre__compile(a,b,c,d,e)
in order to avoid conflict with function names in the libraries when
OPCRE links in the NPCRE library.


The documentation should state that OPCRE is transitional. At some
future date the OPCRE project may be abandoned, or perhaps it will
just remain static for very long intervals.


If having a distinct OPCRE library is not possible or not desirable,
then I vote for option #1 from above. I fear that option #2 may be a
hinderance if both the old and new API's are meshed together. It may
complicate PCRE's coding and introduce confusion for application
developers.


Graycode