from __future__ import *

buy music albums Silver Apples buy mp3 albums Tarrus Riley buy tracks mp3 Kravits buy Reaper albums mp3 buy Kravits albums music buy music Evita CD online albums mp3 Silver Apples download Madonna CD music buy tracks music Kravits download music albums Silver Apples

When using Apache's mod_proxy in a reverse proxying scenario, usually you'll want to take a look at the (seemingly undocumented) X-Forwarded-For header. This header contains whatever the client sent for X-Forwarded-For (if anything), plus the remote IP address of the client.

So, if you're trying to do anything with this header, check for commas and pick out the last piece, because the client can send anything they want to, and you shouldn't ever trust the client:

def get_request_ip(request):
    """get the IP of a request in twisted.web-speak"""
    host = request.transport.getPeer().host
    # Twisted doesn't support IPv6 anyway :)
    if host != "127.0.0.1":
        return host
    header = request.received_headers.get('x-forwarded-for', None)
    if header is None:
        return host
    return header.split(',')[-1].strip()

I gleaned this from reading the Apache 2.0.54 source, I couldn't find any description of the behavior of mod_proxy in Apache's docs, only how to configure it. I was surprised that it even preserved what the client sent!

TurboGears, "the rapid web development megaframework you've been looking for", has just been released. It's the first web framework (for any language) that includes MochiKit in its war chest. TurboGears looks cool because it leverages a lot of very good existing software and wraps it up in a very usable manner. It does not have NIH syndrome. It has excellent documentation and a very nice 20 minute wiki tutorial that covers the whole stack (all the way up to "AJAX" with MochiKit!).

There's a lot of good first impressions to be had with the technology:

• It's not afraid to take advantage of Python 2.4 features (decorators)
• Despite the fact that it has a bunch of dependencies, installation is painless as it's setuptools-based (eggs!)
• It uses Kid for templating. XML in, XML out. This means your templates look like your output and can be tested (for validation, look and feel, etc.) with just a web browser. A web developer's dream come true! If you've used TAL (or ZPT) before, it's similar.
• SQLObject is a pretty good ORM layer, with support for SQLite, MySQL and PostgreSQL. What's especially cool is that you don't actually have to use it, so if you have another way of doing your model layer you really don't have to change.
• The model hooks up to the view by returning a dictionary. These dictionaries are either passed to Kid to render a template, or can be returned to the browser as JSON. There are plenty of other possibilities here (XML, etc.). Perfect for MochiKit integration!
• It comes with a script to make a project using the default template, so a new project is not a blank slate. This is especially useful for new users.
• CherryPy knows how to reload code and templates when they change on disk. This is probably my biggest pet peeve with some of the "competition". Boy do I hate restarting servers!
• It supports all the important platforms (anything unix-like, including Mac OS X, and Windows).

It seems to be quite a complete package. I'd be a little more excited about it if it was built on top of Twisted, but it's probably possible to plug that in to an extent using CherryPy's WSGI support.

Tagalag, by John Wehr, has recently opened its doors. It is a contact manager that allows you to assign tags to email addresses and view tags that have been assigned to you. John is a close personal friend of mine, and he helped us out a bit with MochiBot and MochiKit this summer. Tagalag is cool stuff, and it's free, so go check it out!

It's using MochiKit for the UI, and has a lot of cool features such as GMail and Yahoo! Mail integration with Greasemonkey, a Tagalag box you can throw on your blog or website to make it especially easy for people to tag you, and a Google Maps view of identities in the system that have provided zip codes.

Interesting to software developers is that it supports the XFN vocabulary, and has an XML based API. Locally, all of the data travels over JSON before it hits the MochiKit-laden JavaScript code.

I was taking a look at the AjaxLibraries section of the OSAFoundation wiki, because mochikit.com has been getting a lot of referrals from there. There's a bit of misinformation in the cons section, which I'll clarify in this post:

• Sparse visual effects library

This is fair, but so what? MochiKit is fully compatible with everything else. If you want visual effects, pick a library that does those and use it with MochiKit. It's not trying to do any visual effects right now, except rounded corners -- and that's because it was a contributed feature. JavaScript, particularly in the browser environment, is missing so many other things that making everything blink is not really a priority for us right now. Blinking is totally orthogonal to everything else going on. You know, like the stuff that actually matters.

• AJAX library (called 'Deferred') has limited functionality -- no POST, no access to result in XML, no ability to access HTTP status in error handling.

Wrong, wrong, wrong, and wrong.

The AJAX library, called MochiKit.Async gives you full access to the XMLHttpRequest object throughout the entire process, which lets you do whatever you want. I imagine that the confusion arises because we make GET and JSON really really ridiculously easy. Because they are. There's nothing it can't do, though, because you have full control.

To do a POST (or any other verb), use getXMLHttpRequest() and set one up, use sendXMLHttpRequest(req, postData) to fire it out. If you want an easy way to build the post data, use queryString().

The returned Deferred object will call back with the XMLHttpRequest object upon successful completion (which means you can get XML, or whatever the hell else you want), or if there is an error, the XMLHttpRequestError object has a req object that corresponds to the failed request, and for convenience a number property that corresponds to req.status.

For those not watching the entire blogosphere, here's two pretty good articles/posts about MochiKit that have come up recently:

Andy has put together part 1 of a series of MochiKit tutorials for building a blog application, almost entirely client-side: http://argv0.net/static/mochitut/1/

For a little more commentary on that post, you might look towards the Ajaxian blog coverage.

Jeff Shell put out a little head-to-head between MochiKit and Prototype from a Zope user's perspective: http://griddlenoise.blogspot.com/2005/09/prototypejs-and-mochikit.html

What Jeff doesn't seem to mention in his article is that his AJAX example actually shows Prototype and MochiKit living in harmony (using Element.show and Element.fade from Prototype, with MochiKit's AJAX support). That actually does work. Personally, I'd have demonstrated the AJAX stuff without the Fully.Qualified.Names in that scenario (to show MochiKit in its best light in comparison w/ Prototype), and used showElement instead of Element.show (saves a character, removes a Prototype dependency ;).

MochiKit plays very nice with both the strictest (i.e. Dojo) and the loosest JavaScript development styles (i.e. Prototype) around, because it's very defensively programmed and well exercised in those scenarios. There's one or two places in MochiKit where you pay a price (performance, or extraneous data carried around) if you mucked up Object.prototype, but it actually does let you do that.

Thanks guys!