apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: Binary data in apr dbd - where should buckets come from
Date Fri, 30 Jun 2006 02:59:39 GMT
Quoting Alex Dubov <oakad@yahoo.com>:

> Look, you are not being productive.

I'm sorry you feel that way.

> Please, read my letter carefully to the end.

I did not respond to the points I don't have a good handle on (i.e.  
bucket allocation issues). I'm sure other people that have been  
involved with APR for much longer know a lot more about it. So, I'll  
leave it up to them to answer those questions.

I tried responding to the issues that I think are important for the  
future of DBD API in a way that doesn't say "strings are stupid" or  
"binary data is stupid". I was trying to be inclusive and to provide  
pointers for the API that would ensure people don't have to wrestle  
with wrapping up everything (i.e. keep simple things simple and put  
more effort into complicated stuff).

The "let's do buckets for the lot" didn't seem like a good idea to me  
and it still doesn't. It excludes too many valid use cases of the API  
and is just too complicated for the most simple of use cases. And, if  
we were to implement binary only passing of parameters, we'd break  
binary compatibility from the word go.

But, I could be completely wrong on all these points. I'm sure other  
folks on the list will have their say and whatever turns out good will  
be put into APR.

> I do want to have a good api. I don't know how to
> design it. I need somebody to do the design of the api
> for binary data. I outlined the problem in my last
> message in great details.

Well, I tried suggesting an approach to the API design which I thought  
would satisfy more than one person, but you didn't find that useful.  
That's OK.

Apologies if I'm not responding to the questions you really want  
answered. I'm sure someone on the list eventually will.

-- 
Bojan

Mime
View raw message