On 9/8/2010 10:44 AM, Dalton Calford wrote:

> Come on Jim, don't you think that having a plug in architecture would be
> good for a parser.

Sigh. I've spent way to much of life explaining to the other guys that
the absence of architecturally controlled APIs make plugins unworkable.

No, I don't think a plugable parser is a good idea since the parser
produces a syntax tree that is tightly bound to the compiler, just as
the compiler produces structures that are tightly bound to the runtime.
Sure, you could standardize either, but only at the expense of hobbling
development.

If you want to do that sort thing, put the interface between the runtime
and row store under architectural control and support multiple engines,
each with a parser, compiler, and runtime.

> Why we may even have a low level language that is implemented in the
> database (some sort of Binary Language Representation) that you can use
> instead of the standard. We could have multiple incompatible or
> semi-compatible SQL parsers as standard (perhaps just numbering the
> dialects) while someone else works on Java or other language versions of the
> underlying procedure language.
>
> Why, I am sure we can even put in emulation of the operations(benchmarks) of
> other database systems such as mongodb (external tables mapped to
> /dev/null).
>
> All kidding aside. A parser is tried and tested technology. Everyone has
> written some form of parser in the past while parser generators are
> available. If the system is written correctly, it could be made to be
> easily generated. The big issue is, would it be used?

Actually, arguing about parsers passes the days for many database
architects. The politically correct all go for parser generators until
they get smarter. Then, in their next incarnation, they go for hard
coded recursive descent parsers.

Yacc / Bison -- just say no. More trouble than they're worth.

> Our company just bought a series of other companies. They have systems on
> old versions of Oracle, DB2 etc. Now the clients they use currently work,
> but if we could keep their clients and rework the back end via
> Firebird/Views and Procedures before we attack the front end, then there is
> value there. Redesigning a back end and a front end combined with staff
> retraining makes the project a non-starter. So we are faced with
> maintaining legacy systems that don'r quite fit into our existing
> infrastructure.
>
> I am sure that we are not the only company who has faced a situation like
> this. Having the option is a good thing, even if most users don't even
> realize the power is there. (Filters are a good example of this, in all my
> years I have never seen a firebird/interbase filter but once I found I had a
> need, I had it written and it works well)
>
> The decision would have to lie in the hands of the current developers
> because there is not enough of a need on my part to finance it. So it
> would have to be decided by those who consider such a tool important enough
> to do the work.

The standard next step is to define an ad hoc, database independent,
middle layer that eventually consumes all resources and stops all
development.

>
>
>
>
>
> On 8 September 2010 10:02, Jim Starkey<jstarkey@...> wrote:
>
>>
>> Ooo, ooo! Definitely a MySQL mode. But which of the dozens in
>> mutually incompatible releases would that be? 5.0.x? 5.1.1? 5.1.y?
>> 5.1.z? And home many of the dozens of incompatible operating modes
>> would you include in each?
>>
>> MySQL expects that applications will require porting from x.y.z to
>> x.y.<z+1>. Ugh. On the other hand, their users have been well
>> trained. And they have to support and maintain a whole trail of old
>> releases.
>>
>> My experience has been that users almost never, ever, port a working
>> application from database A to database B. Looking at the issue from a
>> NimbusDB planning perspective, we decided to stick with standard SQL and
>> extensions of our own choosing on the assumption that we will be used
>> for new applications doing forward, not old applications going backward.
>>
>> Do what you think is technically best.
>>
>>
>> On 9/8/2010 6:32 AM, Dalton Calford wrote:
>>> Are you suggesting a 'dialect oracle' ? How about a 'dialect mssql'?
>>>
>>> The big question is, should the parser be a plugin including some system
>>> views that support various databases including their information schema?
>>>
>>> That would be powerful and allow firebird to be a drop in replacement of
>>> many database backends.
>>>
>>> On 8 September 2010 05:44, marius adrian popa<mapopa@...<mapopa%40gmail.com>>
>> wrote:
>>>> what happened to fyracle mode ?
>>>>
>>>> http://www.firebirdnews.org/docs/papers/fyracle_wsw.pdf
>>>>
>>>> i see some of it's components/features would be integrated in 3.0 (see
>>>> the roadmap screeshot)
>>>> it would be nice to have an oracle "mode" for migrations from oracle
>>>>
>>>> also it would be nicer to have full pl/sql support too
>>>>
>>>>
>>> [Non-text portions of this message have been removed]
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>> --
>> Jim Starkey
>> Founder, NimbusDB, Inc.
>> 978 526-1376
>>
>>
>>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376