<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>RE: memcache(3) 1.2.0 released...</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=2>[snip]<BR>
&gt;&gt; [snip]<BR>
&gt;&gt;<BR>
&gt;&gt; This all sounds great.&nbsp; I've been considering on and off making a php<BR>
&gt;&gt; module that wraps your work, but so far the PECL one from Anthony<BR>
&gt;&gt; Dvogal<BR>
&gt;&gt; is meeting our needs.&nbsp; libmemcache is significantly faster, but its<BR>
&gt;&gt; very<BR>
&gt;&gt; hard for me to gauge whether this is just due to the php overhead that<BR>
&gt;&gt; would also be present in a wrapper for libmemcache or not.&nbsp; At the same<BR>
&gt;&gt; time, I'm need to get some practice writing php modules anyway, so I'll<BR>
&gt;&gt; probably do it pretty soon (maybe this weekend).<BR>
&gt;<BR>
&gt; If you do, I'll buy you a beer next time I'm in Seattle... I've been<BR>
&gt; avoiding doing this for one reason or another... hacking the PostgreSQL<BR>
&gt; driver to return bool instead of a string 't' or 'f' (who does that<BR>
&gt; anyway?&nbsp; I mean honestly, how braindead can a driver be anyway?) gave<BR>
&gt; me a bad taste in my mouth and sent me back to Ruby.&nbsp; Look at the Ruby<BR>
&gt; wrapper if you want some hints on how to accomplish this... let me know<BR>
&gt; when you start though in the event that I end up starting on it 1st.&nbsp;<BR>
<BR>
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.&nbsp; Very clean to work with compared to php, IMHO.&nbsp; However, I am responsible for a large amount of php code and need to continue maintaining it :)<BR>
<BR>
So, I've been thinking about the wrapper more, and it seems there is a fundamental design decision I need to make right off.&nbsp; Should I...<BR>
<BR>
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.&nbsp; (kind of like the original php4.x and prior mysql api which very closely models the c api).<BR>
<BR>
or...<BR>
<BR>
2) Wrap the c api into an object oriented archtecture to make it easier to use/more intuitive to php users.<BR>
<BR>
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.<BR>
<BR>
The benefits I see on option #2, are that it may be more widely adopted and used by others.&nbsp; 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.<BR>
<BR>
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.&nbsp; It's really a toss up for me, I'd be able to use it either way.&nbsp; 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.&nbsp; Are most others using php 5.x or 4.x?&nbsp; I plan to support both, but I'd also like to get an idea of what others need most to start with.<BR>
<BR>
John McCaskey<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>