[phpdba] Re: so who's there?
Hello,
on 03/08/2007 04:57 AM Lukas Kahwe Smith said the following:
>> Any particular reason why the list was not created on a more capable
>> list service, like Yahoo Groups, for instance?
>
> Not really, well I guess I personally prefer this over the services of a
> large organization, where people have to create accounts.
Erm... in Yahoo groups you do not have to create accounts. You can just
subscribe and unsubscribe by e-mail. Accounts are only needed to access
Web resources associated to the group.
Maybe you were thinking of Google Groups. If there is a thing that
Google does not lead yet, it is in the mailing lists/discussion groups
field.
>>> However, over time I guess this list will hopefully will define itself
>>> as we discuss topics that come up. So with that I encourage all of you
>>> to post about challenging new features you are currently working on.
>>
>> I am not working in any new feature for Metabase right now. The last
>> feature that I developed, as you know was the pattern matching
>> abstraction. It is still not perfectly solved because different
>> databases may handle patterns with case sensitiveness or not. I have not
>> invested time in finding a solution either.
>
> Yeah, I remember. One thing that we found out back then is that we would
> probably write a callback for SQLite IIRC:
I was not thinking of SQLite. I was thinking that MySQL LIKE operator is
case insensitive (which is what most people want) but in other databases
LIKE is case sensitive by default.
>> Maybe I got the wrong impression, but it felt there wasn't much will to
>> really cooperate and reach a consensus. This is a shame for the PHP
>> community because we loose the opportunity to have a single solution
>> that gathers greater adoption and more contributions.
>
> Like I said above, in the particular case you mentioned, I think it was
> just that the topic kinda fell of the radar, I presume because of time
> constraints, rather than Igor "actively" ignoring your proposal.
I don't know, but he mailed several people including me to give
opinions. He proposed an approach. I proposed something different more
consistent with the previous definition of indexes and schemas, and he
insisted on his approach. Maybe I got it wrong, but it felt pretty much
that there was not interest to reach a consensus.
> So the purpose of the list is not to change today's reality of a
> multitude of packages, but to at least foster the exchange of ideas (and
> maybe even some code). Back when I was active on MDB/MDB2 I frequently
> looked at other layers, like on going development of Metabase (pattern
> matching etc) and PEAR::DB (error code abstraction), as well as ADODB
> ("smart" transaction), Creole (sequence/autoincrement tweaks). I am
> hoping that with this list, we will have a big bigger exchange of ideas.
> That when someone is trying to tackle a new tricky topic, that he can
> ask here for advice etc.
If you want an honest opinion, I am afraid that goal will hardly happen,
I mean most people will not share good ideas.
While there is a sense of competition, many packages for the same
purposes, people with good ideas already implemented will act
defensively and avoid sharing the details those ideas to not encourage
plagiarism. They will come to the list but remain on spy mode, i.e.
watching others bragging about good ideas of their packages.
Nothing wrong with this, it is just a consequence of ego driven
motivation that fuels the development of many open source projects.
>> For instance, what database API do you think Delphi for PHP supports?
>
> Actually I was wondering the same thing, when I was looking over their
> press releases the other day. But again, I do not hope to consolidate
> the available solutions with this list. The goal is to pool know how to
> at least prevent each of us wasting time on figuring out things one of
> us has already gotten to work.
No, consolidating all solutions will never happen, it is too late. I
have a better idea.
There is something good that worked very well in the Java world: JCP -
Java Community Process. Vendors (People and companies) with common
interests sit down and agree on API specifications. When the
specification is finished, each vendor is free to implement their own
version of their specification.
The advantage of this is that application developers are not tied to a
specific implementation. They develop applications using the same APIs
that may run with different API implementations.
I have written more about this below in this blog post. Look for the
section about "PHP lacks of formal standard specifications".
http://www.phpclasses.org/blog/post/52-Recommended-PHP-frameworks.html
The article is about general purpose frameworks, but restricting
ourselves to database abstractions, it would be the almost the same
writing a specification of PHP DBC .
Once such specification was ready, each database abstraction developer
could write wrappers on even full implementations from scratch that
would implement the specified API.
There would be a single base of unit test scripts that could be used to
certify the compliance of all implementations.
Once you have this all working, then all database applications and
components could be more interoperable.
Let me give a simple but concrete example. Remember the SQL LIKE pattern
matching abstraction that I implemented in Metabase and then you adapted
to PEAR::MDB2?
With that I implemented an auto-complete plug-in for forms text inputs
that pulls completion texts from any database.
That works with Metabase API. To support PEAR::MDB2 you developed an
adapter to use PEAR::MDB2 API for the same purpose. There is also an
adapter for MySQL with the native API. But what about other database APIs?
If there was a common API specifications, all database abstractions that
provide an implementation for that API would have been supported.
The auto-complete plug-in is just an example that can be seen in action
here:
http://www.meta-language.net/forms-examples.html?example=test_auto_complete
But there are more, like for instance the plug-in to link multiple form
select inputs here:
http://www.meta-language.net/forms-examples.html?example=test_linked_select
And there will be more and more.
So my idea can be summarized as gathering all developers that implement
database abstraction packages, give up any personal differences, and sit
down to work on a common database API specification from which we all
can benefit.
--
--
Regards,
Manuel Lemos
Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
RSS Feed