[Zope] Brainstorm: Zope behind proxying cache?

[Sam Gendler]

I am in the process of working on an Akamaization product for Zope.  If you are
unaware, Akamai is a company that has a very high speed worldwide network.  They
offer (for a fee), the ability to store all of your static objects on their
network.  You modify the URL in the html documents that reference those objects,
so that the URL is in a special format.  The browser is then able to get the
object from the closest available server, which is usually not farther than your
ISPs local point of presence. Generally, people only store images, midi files,
wav files, etc on the akamai network, but there is no reason not to put html
files there as well.  There is no actual upload process.  You just change the
URL, and the first time somebody requests it from the akamai network, it is
retrieved from your web server and distributed across their network. Every time
an object is modified, the special URL is changed (the url includes the
checksum).  This means that every time you modifiy an object, the akamai network
will pick up the change.

My intent was to just create some simple subclasses of Image and File in zope.
Each would have, in addition to the url method, an akamai url.  When you include
the image or file in your document, you would just use a <dtml-var
image.akamaiurl> tag to get the akamai tag.  Additionally, it will be possible
to set a property (that only needs to be available via acquisition) that says
whether to sue the akamai url or the normal url.  That way, when you are
developing the site, you can use the akamaiurl tag, but still retrieve the
images from the local zope server.  When you publish the site, you disable debug
mode, and all akamai urls will be sent correctly.

I should have time to actually do the work by the end of the month (since I have
a client that needs it by Feb 17).  However, I have no idea how much Akamai
charge for the service.

-sam

Jonathan wrote:

> Hi,
>
> Been brainstorming a little while about modifying HTTP requests
> combined with a high speed cache in front of a dynamic source of
> data, such as Zope.
>
> Idea: Put a proxying cache with content negotiation, rewriting of
> requests etc. in front of Zope. First time a page is requested
> (client requests it from the proxy which knows where to get it
> because it's configuration files tell it how to handle a request) it
> is cached. The next request is served directly from the cache. As
> soon as a page changes it is fetched from Zope and cached again.
>
> It would also allow you to use any mix of static and dynamic content,
> because pages that stay the same are served directly from the cache
> and Zope is never hit to serve that page. Allows to use Zope as a
> content management tool too.
>
> So what's your view? I know that a request can be modified behind the
> scenes based on the data the client supplies - request, filetype,
> language, browser type, IP address etc. It's also possible to cache
> the files requested, but I am not sure how the cache would
> communicate with Zope and vice versa.
>
> The HTTP protocol offers some hooks to cache a file for a limited
> time only if I am not mistaken, but the ideal solution in my view
> would be a button in Zope called 'Publish' which would send a message
> to the cache resulting in the removal of that particular page...
>
> Just brainstorming here :)  Anyone with suggestions, comments?
>
> Thnx
> Jonathan
>
> --
> UR Communications - Solutions for a wired world
> Who, what & where @ http://www.ur.nl/
>
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )