memcache(3) 1.2.0 released...

[John McCaskey]

[snip]
>> [snip]
>>
>> This all sounds great.  I've been considering on and off making a php
>> module that wraps your work, but so far the PECL one from Anthony 
>> Dvogal
>> is meeting our needs.  libmemcache is significantly faster, but its 
>> very
>> hard for me to gauge whether this is just due to the php overhead that
>> would also be present in a wrapper for libmemcache or not.  At the same
>> time, I'm need to get some practice writing php modules anyway, so I'll
>> probably do it pretty soon (maybe this weekend).
>
> If you do, I'll buy you a beer next time I'm in Seattle... I've been 
> avoiding doing this for one reason or another... hacking the PostgreSQL 
> driver to return bool instead of a string 't' or 'f' (who does that 
> anyway?  I mean honestly, how braindead can a driver be anyway?) gave 
> me a bad taste in my mouth and sent me back to Ruby.  Look at the Ruby 
> wrapper if you want some hints on how to accomplish this... let me know 
> when you start though in the event that I end up starting on it 1st.  

I hear that, I've been increasingly fustrated with php lately after doing a far bit of work in python and creating some python extensions as well as embedding it.  Very clean to work with compared to php, IMHO.  However, I am responsible for a large amount of php code and need to continue maintaining it :) 

So, I've been thinking about the wrapper more, and it seems there is a fundamental design decision I need to make right off.  Should I...

1) Wrap the c api as closely as possible using procedural functions and return a resource id to the php programmer they need to track like the memcache struct in the c api.  (kind of like the original php4.x and prior mysql api which very closely models the c api).

or...

2) Wrap the c api into an object oriented archtecture to make it easier to use/more intuitive to php users.

The benefits I see of option #1, are that it keeps the two apis very close so if the c api changes it may be easier to update, and since I use the c api directly quite a bit, it means I don't have to remember two different apis.

The benefits I see on option #2, are that it may be more widely adopted and used by others.  It may be easier for others to use, and finally if a change occurs in the c api it is not likely to directly affect the php api and I could update the module without having to break php end users code.

I'd like to get feedback from those on the list who have already commented in support of a wrapper module as to which direction they prefer to see it go.  It's really a toss up for me, I'd be able to use it either way.  Also, I'm stuck with php 4.x for the moment for most of my work, so my first desire will be to support it.  Are most others using php 5.x or 4.x?  I plan to support both, but I'd also like to get an idea of what others need most to start with.

John McCaskey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20050111/6f50543c/attachment.html