Log on to your server as root (either directly or using sudo su), then install the Memcache daemon through apt:
apt-get install memcached

Once installed you need to install the Memcache module into PHP. This is done through PECL which in turn is installed through PEAR. When they are both installed, you need to run the command:
pecl install memcache

This will install the memcache extension, and once done will tell you to add the the line “extension=memcache.so” into your php.ini file. I prefer keeping these in separate files (so that the php.ini file can be updated). The easy way to do this is:
echo “extension=memcache.so” > /etc/php5/conf.d/memcache.ini

And finally, reload Apache
/etc/init.d/apache2 reload

If successful, Memcache will now appear in your phpinfo()

If you are having problems getting your app to build and run on your iPhone or iPod touch, the following may help you:

CERTIFICATES

All certificates have to be included in the ‘login’ Keychain (section) of the ‘Keychain Access’ app, which is used to manage all types of security on your Mac. There are other sections in Keychain Access; on my MacBook these are ‘System’ and ‘System Roots’. Ignore these, and ensure that the ‘login’ section is the default section. The default section shows up in bold typeface. If ‘login’ is NOT in bold, but some other section is, you can make ‘login’ the default section by right-clicking it, and selecting ‘Make Keychain “login” Default’. Some developers have reported that their default keychain is automatically (and inexplicably) switched to something other than ‘login’.

You need to have, in your login section of Keychain Access, the following 2 certificates:

1. A certificate called ‘Apple Worldwide Developer Relations Certification Authority’. Apple also calls this the WWDR intermediate certificate. You need this certificate on your keychain (i.e. on your Mac, and available to Xcode) because this is the trusted certificate that signs your own developer certificate.

2. Your own developer certificate, which has been signed by the WWDR certificate. Your developer certificate is the one that Xcode needs. Xcode will read in this certificate when it builds your iPhone application, and because your certificate has been signed by the WWDR certificate, Xcode needs access to the WWDR certificate too, which is why it must be on your keychain.

(Note that the pair of keys (e.g. Joe Bloggs, private key, and Joe Bloggs, public key) that were created when the CSR was created, are no longer needed. You can safely delete these two files from Keychain Access after you have added your developer certificate to Keychain Access. The keys were only needed to authenticate your developer certificate from Apple.)

ERRORS

Errors you may get:

Error: “A valid signing identity matching this profile could not be found in your keychain”

Solution: Most likely that you have not downloaded the necessary WWDR certificate from the Apple developer site. There is a link to download this certificate in the ‘Certificates’ section of the developer portal. If you do have the certificate in your keychain, make sure that it has not expired (unlikely, as mine is valid until 2016). Also make sure that your developer certificate has not expired (these seem to be valid for only 12 months at a time).

Error: “Code Sign error: A valid provisioning profile matching the application’s Identifier (abcdef123456.com.yourdomain) could not be found”

Solution: remove “abcdef123456.” from the start of the Bundle Identifier in Xcode (.plist file)

Error: nothing happens when I click a button on the Apple site

Solution: DO NOT USE Firefox for visiting Apple’s Developer sites. There are problems when you click buttons, e.g. to Add, Delete or Edit items in your program portal (nothing happens in Firefox), leaving you uncertain about whether anything has happened. Apple’s own browser, Safari, works properly. I have not tried any other browser, but beware!

CSR COMMON NAME

When you create your CSR, the “common name” that you specify must match your own name, or the name of one of your development team that you have specified in the portal. Apple appears to add the prefix “iPhone Developer: ” to the common name, and adds a 10-character suffix in parentheses, e.g. (CXW34YTRE4), but all you need is the developer’s first and last name.

STARTING FROM SCRATCH

If all else fails, START OVER:

1 Delete the WWDR certificate and your developer certificates from Keychain Access
2 Ensure that the login keychain is set as the default keychain in Keychain Access
3 Download the WWDR certificate and add it to your keychain in the login section
4 Use Keychain Access to generate a CSR (Certificate Assistant… Request a Certificate…) for a developer
5 Submit the CSR to the Apple portal
6 When the developer certificate is ready, download it to your Mac and add it to your keychain in the login section
7 In the Apple portal, specify the unique device ID (UDID) of your iPhone or iPod touch. You can find the device’s UDID in the Window… Organizer section of Xcode. The ID is the 40 character “Identifier” string in the “Summary” tab (e.g. 4ada8edc85bfdd3947696cb3277a8c7f731fb6c3)
8 In the Apple portal, choose an App ID name. This can be anything, it is not related to any other data. However, the Bundle Identifier that you choose here MUST match the Bundle Identifier used in your Xcode .plist file, e.g. “com.mydomain”
9 In the Apple portal, create a provisioning profile. The 3 ingredients for this are the name(s) of your developer certificates, your unique device ID(s) (UDID(s)), and your App ID. When you download this file, it will have a .mobileprovision extension. After you have downloaded it, open it in Finder, and drag it to the Xcode icon in your dock. The profile should now appear in Xcode. To check, go to the Xcode “Window… Organizer” menu and look under “iPhone Development… Provisioning Profiles”. If all is ok, you should not see any yellow error messages, and your profile should appear in the “Name” list.
10 Do a clean build, so that previous precompiled headers and object files are deleted. In Xcode, choose “Build… Clean All Targets”, then “Build… Build and Run”. If your code compiles with no errors, Xcode will upload the app to your iPhone or iPod touch, using the USB cable attached to your device.

http://example.com/users/

http://example.com/users/{user} (one for each user)

http://example.com/findUserForm

http://example.com/locations/

http://example.com/locations/{location} (one for each location)

http://example.com/findLocationForm

The client typically a webbrowser needs to construct HTTP requests and parse XML or HTML responses.

XML-RPC uses XML protocol to make Remote procedure calls to execute functions defined on objects, over the network.

An RPC application might define operations such as the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<em>getUser()</em>

<em>addUser()</em>

<em>removeUser()</em>

<em>updateUser()</em>

<em>getLocation()</em>

<em>addLocation()</em>

<em>removeLocation()</em>

<em>updateLocation()</em>

<em>listUsers()</em>

<em>listLocations()</em>

<em>findLocation()</em>

<em>findUser()</em>

The client needs to construct an XML request and parse the XML response.

Comparison

REST is an HTTP based protocol. Whereas XML-RPC is XML based.

IMO, REST being an HTTP based protocol works best when the client is a browser. XML-RPC on the other hand is XML based. So no assumption is made about the client which is going to use the protocol.

When the client is a browser, more efforts need to be put in by the client to use XML-RPC than to use REST.

An advantage of REST over XML-RPC is that each object has its own URL and can easily be cached, copied, and bookmarked.

Advantage of XML-RPC is that it is client independant. Any sort of client be it a desktop application a mobile application, a mashup using information from your site can easily integrate with XML-RPC.

Overall I think REST has its advantages in the browser world. But as more and more applications are using the web as a platform and accessing it through a variety of methods other than web browsers XML-RPC has and edge over REST.

Conclusion

Web services should provide and XML based interface like XML-RPC. The could also provide a RESTful interface built on top of XML-RPC to support browser based clients.

You can “autorelease” objects. This means the retain count isn’t immediately decreased, but is decreased the next time the current autorelease pool is drained.

iOS apps have an event loop in which your code runs. After each iteration of the event loop, the autorelease pool is drained. Any object with a retain count of 0 is released.

By default, autoreleased objects are returned by methods that don’t begin with new, copy, mutableCopy, retain or init. This means you can use them immediately but if you don’t retain them the object will be gone on the next iteration of the run loop.

If you fail to release retained objects but no longer reference them then you will have a memory leak, this can be detected by the leaks tool in Instruments.

One strategy is to autorelease everything returned by the above named methods and store objects in retain properties (or copy for strings). In your object’s dealloc method, set all your properties to nil. Setting a retain/copy property to nil releases the object that it currently points to. As long as you don’t have any circular references (avoided by not using retain properties for “parent” objects such as delegates), you will never encounter any leaks.

http://framethink.wordpress.com/2011/01/17/how-facebook-ships-code/

-- This is a comment
DoSomething();

-- This is another comment.
ReDoSomething();

But the double hyphen is not very convenient for commenting multiple lines. Like in C language, there is a multi-lines comment:

--[[
This is a ...
multiline...
comment!
--]]
DoSomething();

This multiline or block comment is really cool since you can enable or disable a piece of code using a single hyphen.
Hereafter, the function mySqr_v1 is commented:

--[[
function mySqr_v1(a)
	return a * a;
end
--]]

function mySqr_v2(a)
	local b = a*a;
	return b;
end

and now, you can simply uncomment it with one hyphen:

---[[
function mySqr_v1(a)
	return a * a;
end
--]]

function mySqr_v2(a)
	local b = a*a;
	return b;
end

Now both functions are active!

Wath-out: –[[ .... --]] is the right manner. I often see –[[ .... ]]– which seems to work but it’s wrong.

In Cocoa, each object keeps track of how many times it is being referenced (specifically, the NSObject base class implements this). By calling retain on an object, you are telling it that you want to up its reference count by one. By calling release, you tell the object you are letting go of it, and its reference count is decremented. If, after calling release, the reference count is now zero, then that object’s memory is freed by the system.

The basic way this differs from malloc and free is that any given object doesn’t need to worry about other parts of the system crashing because you’ve freed memory they were using. Assuming everyone is playing along and retaining/releasing according to the rules, when one piece of code retains and then releases the object, any other piece of code also referencing the object will be unaffected.

What can sometimes be confusing is knowing the circumstances under which you should call retain and release. My general rule of thumb is that if I want to hang on to an object for some length of time (if it’s a member variable in a class, for instance), then I need to make sure the object’s reference count knows about me. As described above, an object’s reference count is incremented by calling retain. By convention, it is also incremented (set to 1, really) when the object is created with an “init” method. In either of these cases, it is my responsibility to call release on the object when I’m done with it. If I don’t, there will be a memory leak.

Example of object creation:

NSString* s = [[NSString alloc] init]; // Ref count is 1
[s retain]; // Ref count is 2 – silly
// to do this after init
[s release]; // Ref count is back to 1
[s release]; // Ref count is 0, object is freed
Now for autorelease. Autorelease is used as a convenient (and sometimes necessary) way to tell the system to free this object up after a little while. From a plumbing perspective, when autorelease is called, the current thread’s NSAutoreleasePool is alerted of the call. The NSAutoreleasePool now knows that once it gets an opportunity (after the current iteration of the event loop), it can call release on the object. From our perspective as programmers, it takes care of calling release for us, so we don’t have to (and in fact, we shouldn’t).

What’s important to note is that (again, by convention) all object creation class methods return an autoreleased object. For example, in the following example, the variable “s” has a reference count of 1, but after the event loop completes, it will be destroyed.

NSString* s = [NSString stringWithString:@"Hello World"];
If you want to hang onto that string, you’d need to call retain explicitly, and then explicitly release it when you’re done.

Consider the following (very contrived) bit of code, and you’ll see a situation where autorelease is required:

- (NSString*)createHelloWorldString
{
NSString* s = [[NSString alloc] initWithString:@”Hello World”];

// Now what? We want to return s, but we’ve upped its reference count.
// The caller shouldn’t be responsible for releasing it, since we’re the
// ones that created it. If we call release, however, the reference
// count will hit zero and bad memory will be returned to the caller.
// The answer is to call autorelease before returning the string. By
// explicitly calling autorelease, we pass the responsibility for
// releasing the string on to the thread’s NSAutoreleasePool, which will
// happen at some later time. The consequence is that the returned string
// will still be valid for the caller of this function.
return [s autorelease];
}
I realize all of this is a bit confusing – at some point, though, it will click. Here are a few references to get you going:

Apple’s introduction to memory management.
Cocoa Programming for Mac OS X (3rd Edition), by Aaron Hillegas – a very well written book will lots of great examples. It reads like a tutorial.
If you’re truly diving in, you could head to Big Nerd Ranch. This is a training facility run by Aaron Hillegas – the author of the book mentioned above. I attended the Intro to Cocoa course there several years ago, and it was a great way to learn.

Your .h file:
#import

@interface SendEmailViewController : UIViewController  {
IBOutlet UIButton *button;
IBOutlet UITextField *messageText;
IBOutlet UIButton *backgroundButton;
}

@property (nonatomic, retain) UIButton *button;
@property (nonatomic, retain) UITextField *messageText;
@property (nonatomic, retain) UIButton *backgroundButton;

-(IBAction)sendMail:(id)sender;
-(IBAction)textFieldDoneEditing:(id)sender;
-(IBAction)backgroundClick:(id)sender;

@end
And now your .m file:
#import "SendEmailViewController.h"

@implementation SendEmailViewController

@synthesize button, messageText, backgroundButton;

-(IBAction)textFieldDoneEditing:(id)sender {
[sender resignFirstResponder];
}

-(IBAction)backgroundClick:(id)sender {
[messageText resignFirstResponder];
}

-(void)displayAlert {
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Email Sent" message:@"Thank you for contacting me" delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil];
[messageText setText:@""];
[alert show];
[alert release];
}

-(void)displaySheet {
NSString *msg = nil;
msg = [[NSString alloc] initWithFormat:@"Send Email? Your message:\"%@\"", messageText.text];
UIActionSheet *actionSheet = [[UIActionSheet alloc] initWithTitle:msg delegate:self cancelButtonTitle:@"Not yet" destructiveButtonTitle:@"Yes" otherButtonTitles:nil];
[actionSheet showInView:self.view];
[actionSheet release];
[msg release];
}

-(void)actionSheet:(UIActionSheet *)actionSheet didDismissWithButtonIndex:(NSInteger)buttonIndex {
if( !(buttonIndex == [actionSheet cancelButtonIndex]) ){
NSString *post = nil;
post = [[NSString alloc] initWithFormat:@"message=%@",messageText.text];
NSData *postData = [post dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
NSString *postLength = [NSString stringWithFormat:@"%d", [postData length]];
NSMutableURLRequest *request = [[[NSMutableURLRequest alloc] init] autorelease];
[request setURL:[NSURL URLWithString:@"http://www.yourserveraddy/yourScript.php"]];
[request setHTTPMethod:@"POST"];
[request setValue:postLength forHTTPHeaderField:@"Content-Length"];
[request setValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-Type"];
[request setHTTPBody:postData];
[ NSURLConnection connectionWithRequest:request delegate:self ];

[post release];
[self displayAlert];
}
}

-(IBAction)sendMail:(id)sender {
[self displaySheet];
}

- (void)didReceiveMemoryWarning {
// Releases the view if it doesn't have a superview.
[super didReceiveMemoryWarning];

// Release any cached data, images, etc that aren't in use.
}

- (void)viewDidUnload {
// Release any retained subviews of the main view.
// e.g. self.myOutlet = nil;
}
- (void)dealloc {
[super dealloc];
[button release];
[messageText release];
[backgroundButton release];
}
And lastly your PHP file:
 $message = $_REQUEST['message'] ;
mail( "recipient@server.com", "Test Message", $message );
?>