Re: [pcre-dev] New API for PCRE

On Sat, 8 Jun 2013, Thorsten Schöning wrote:

> > An application may use either OPCRE or NPCRE, but not both.
>
> Why should one need that restriction if NPCRE already is a dependency
> for OPCRE and therefore must be used in an application? Why shouldn't
> one be able to use both APIs, especially with different function
> names, if one is forced to build and link both libraries?

My thought was that the application only has a dependency on OPCRE.
OPCRE would contain NPCRE but not expose its definitions or functions
to the application.

I think one of the drivers for a new API is that the current (int)
option bits are pretty much all used up. I don't know how the new API
might address that. I'm saying that OPCRE would still define its
options as (int) while the equivalent set of options in NPCRE might
not fit in a single (int).

I don't feel comfortable with option #2 whereby both the old and new
could coexist and be utilized together.


> > 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.
>
> I don't see the benefit of an OPCRE for maintainers or users, users
> who don't want or are able to upgrade at least should be in a position
> to use the latest versions of "old PCRE" without changing any of their
> infrastructure and this would mean that old PCRE simply stays
> untouched as it is and the new API is simply that, a new library which
> one can use or not.

There it seems you're suggesting option #1 and that's fine with me.
Let the new API be a solid basis for the future without being limited
by concerns for compatibility with the old API. That's probably the
best and easiest approach.

My suggestion of OPCRE was for a wrapper that could allow many current
(old) applications to recompile or just re-link and thereby be able to
gain up-to-date NPCRE benefits such as any new pattern features, speed
improvements, security fixes, etc. It would not be a solution for all
applications because it would probably not attempt to encompass all of
the features & options available in PCRE 8.33.

In any case, my preference is to avoid the new API trying to contain
both the old and the new interfaces. Perhaps the determination for
having any level of old compatibility depends upon the specifics of
what the new interface will be.


Regards,
Graycode