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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]
>> 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
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
--
Regards,
Max Carlson
OpenLaszlo.org
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
