[Laszlo-dev] [Laszlo-user] API change proposal: LzView.add/removeProxyPolicy()

[David Temkin]

How about extend the dataprovider API to include the features that Max  
is adding?

Though I still don't understand exactly what he's doing with media.  
Should media *ever* be proxied? I don't think so, given that  
transcoding is no longer useful -- really, we should deprecate that  
altogether -- and the browser can load media from remote sites.

Under what circumstances should media be proxied?

On May 29, 2008, at 12:36 PM, Henry Minsky wrote:

> For data requests, the DataProvider API currently does not currently  
> have
> any method to set the proxy server URL explicitly, but I would like  
> to add  such a feature.
>
> The current default system data provider is an instance of  
> LzHTTPDataProvider, which uses
> instances of LzHTTPDataRequest to encapsulate requests.
>
> Currently the way it works is when a data request is made, LzDataset  
> builds a HTTPDataRequest object
> and passes it to the default data provider via the doRequest()  
> methods.
>
>
> So if we add a new "proxyhost" property to nodes (or if that is too  
> broad, to LzView and to LzDataset), then if there is a proxyhost  
> property set on the dataset, it will get stuck into the  
> HTTPDataRequest, and then LzHTTPDataProvider can use that value. If  
> it is not set, then
> the proxy host will default to the current behavior of using the  
> application's own URL as the proxy server address.
>
>
>
> On Thu, May 29, 2008 at 3:22 PM, Henry Minsky  
> <henry.minsky at gmail.com> wrote:
> I think the intention is that this applies to not just data but to  
> media loading as well, which is outside the scope of the
> DataProvider API.
>
>
> On Thu, May 29, 2008 at 3:07 PM, David Temkin <temkin at laszlosystems.com 
> > wrote:
> Max, Henry,
>
> Can this be solved using the existing mechanism of a custom  
> dataprovider, which could implement a proxy policy? That was one  
> intention of the dataprovider API.
>
> Better to do this in one place, as opposed to adding a new API for  
> this.
>
> - D.
>
>
>
> On May 28, 2008, at 4:43 PM, Max Carlson wrote:
>
> Sounds good to me!  By the way, I filed a bug to track the proxy  
> policy API change: http://jira.openlaszlo.org/jira/browse/LPP-6058
>
> Can you file one for doing the same with the proxyhost attribute?   
> Thanks!
>
> Henry Minsky wrote:
> A related issue, it would be nice to be able to specify the URL of  
> the proxy host, instead of it being
> hardcoded to be the app url. How about a proxyhost attribute that  
> you can set in a similar manner?
> On Wed, May 28, 2008 at 3:00 PM, Max Carlson <max at openlaszlo.org <mailto:max at openlaszlo.org 
> >> wrote:
>   Hi Folks,
>   I was thinking of deprecating the LzView.add/removeProxyPolicy()
>   APIs in favor of a new, simpler system.  The current API looks like
>   this:
>   LzView.addProxyPolicy ( f )
>   Adds a function which can decide how the media at a given URL should
>   be loaded
>   @param Function f: A function that takes a URL as a string and
>   returns one of true, false, or null meaning respectively that the
>   request should be proxied by the LPS server; made directly to the
>   URL; or should be passed to the next policy function in the list.
>   The default policy function returns the value of canvas.proxied
>   LzView.removeProxyPolicy ( f )
>   Removes a proxy policy function that has been added using
>   LzView.addProxyPolicy
>   @param Function f: The function to remove from the policy list
>   @return Boolean: Returns true if the function was found and removed,
>   false
>   if not
>   Instead, each view would be able to set its own proxy policy.  If a
>   view does not have an explicit proxy policy set, it looks up the
>   parent chain until it finds one.  The canvas always has a default
>   proxy policy set. Views can change their proxy policy like this:
>   anyview.setProxyPolicy ( f )
>   Sets a proxy policy function on a per-view basis.
>   @param Function f: The function to use for this view's proxy policy
>   Let me know what you think!
>   --     Regards,
>   Max Carlson
>   OpenLaszlo.org
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com <mailto:hminsky at laszlosystems.com>
>
> -- 
> Regards,
> Max Carlson
> OpenLaszlo.org
>
>
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
>
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20080529/77d855df/attachment.html