[Laszlo-dev] Re: serverless operation toplevel attribute

Adam Wolff adam at laszlosystems.com
Mon Jan 24 08:23:24 PST 2005


This makes sense. I'll implement the global switch this way and 
provide a way to override it -- even if we don't document it for 3.0

A

Oliver Steele wrote:
> On Jan 19, 2005, at 12:54 PM, Adam Wolff wrote:
> 
>> I can easily accomodate this. I still think that I should be able to 
>> make media requests bypass the proxy on a request-by-request basis.
>>
>> Consider the case where I have some gif resources and some jpg 
>> resources. I need the server to transcode the gifs, but I would 
>> probably want to bypass the server for the jpgs.
>>
>> I also think that overloading the 'cache' argument to setSource(and 
>> renaming it) is the best entry point for this.
> 
> Is the only case for this, the case where some requests are transcoded 
> and some are not?
> 
> If so, how about adding a pluggable policy for request resolution, 
> instead of putting this in each setSource() call?  For example:
>    function proxyRequiredFiles(url) {
>      var suffix = ...;
>      var supportedFiles = {'jpg': 1, 'jpeg': 1, 'mp3': 1};
>      if (canvas.proxied && !supportedFiles[suffix])
>        return makeProxyRequest(url);
>      return url;
>    }
>    LzView.setRequestPolicy(proxyRequiredFiles);
> 
> With a pluggable policy, you can use the declarative syntax for 
> initialization:
>    <view resource="http://media.com/logo.gif"/>
>    <view resource="http://media.com/logo.jpg"/>
> and for constraints:
>    <view resource="${parent.logo}"/>
> A policy that directs *.jpeg and *.jpg files directly to the named 
> host, and other files to the proxy, will have the correct result and 
> will be applied centrally, instead of replicated at each request site.
> 
> If setSource() is the only way to do this, then I think you need 
> something like this for initialization:
>    <view oninit="setSource('http://media.com/logo.gif', ...)"/>
>    <view resource="http://media.com/logo.jpg"/>
> and constraints are considerably more complicated.
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev


More information about the Laszlo-dev mailing list