Re: Using Akamai with WebObjects

Very true.  The Akamai URLS are fairly complex and when you change an 
image you must increment a portion of the url to indicate to Akamai that 
it must re-aquire the image rather than go from a cached version (much 
like DNS).  One way to make this easy is to create a component (that you 
extend) which replaces all of the regular image URLs with akamaized urls 
(at runtime).  I would never suggest using WebObjects elements, partly 
for the reason you just described.   To garner the greates speed 
improvements from a move to akamai, replacing the urls at runtime might 
facilitate the easiest programming, but obviously not the fastest app.

I would not suggest attempting to use GoLive or DreamWeaver with 
akamaized urls, this would be an incredible burden unless there is a 
GoLive or Dreamweaver plugin that takes care of it.

--asa


Aristedes Maniatis wrote:

> I'm curious about that statement. Even if you aren't using Akamai, why 
> would you put static image URLs in WebObjects elements rather than 
> code them directly in the html as you suggest below? If you create 
> WebObjects elements for every static image, surely that means you 
> can't use editors like GoLive to assemble the html parts of your 
> pages. And browsers can't cache the images as easily.
>
> Ari Maniatis
>
>
>
> On 26/03/2004, at 8:37 AM, Asa Hardcastle wrote:
>
>> To maximize your speed improvements I would suggest hard-coding your 
>> image references (i.e. - in the html code itself) I realize this is a 
>> very un-WebObjects approach, kind of like programming in C, but if 
>> your ultimate goal is speed, you might consider anyway.
>
>
>
>
> -------------------------->
> ish group pty ltd
> 7 Darghan St Glebe 2037 Australia
> phone +61 2 9660 1400   fax +61 2 9660 7400
> http www.ish.com.au | email [email protected]
> PGP fingerprint 08 57 20 4B 80 69 59 E2  A9 BF 2D 48 C2 20 0C C8
>
>
>