1. Yes 2. Yes, My sample implementation is now doing this 3. To some extent. Developers have a lot of control using the cache-control headers. Containers are likely to require a minimum value
On Wed, May 7, 2008 at 4:40 PM, Graham Spencer <[EMAIL PROTECTED]> wrote: > Thanks Louis. A few minor questions: > > [1] I assume DEFAULT should also include CSS files. It might make sense to > base DEFAULT not on pattern matching targets but rather on the context (e.g. > <IMG>, CSS, etc.). > > [2] Will CSS files be parsed to extract background images and such? > > [3] Should we give developers control over timeouts? > > --g > > > On Tue, May 6, 2008 at 4:48 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > Many containers offer the ability to rewrite links to use their proxy > > loading mechanism using *gadgets.io.getProxyUrl() *Typically the > > generated proxy URL can be expected to give better download performance for > > users of that particular container and also potentially reducing the load on > > gadget developer backends. Currently however there is no standard way for a > > gadget to have links in its generated markup be rewritten to use the proxy > > URL format. I would like to propose creating a new feature to allow for > > rewriting of links in generated gadget content > > > > Create a new standard gadget feature called *proxy-rewriter *which > > allows gadgets to control whether they want content re-writing enabled. > > Containers can choose to turn the feature on by default for all gadgets and > > gadgets can use this mechanism to opt-out. > > > > An 'include' param is used to control which URLs to rewrite: > > > > - ALL - All URLs in the content > > - DEFAULT - is recognized static file extension types such as .js, > > .png, .gif ... > > - NONE - disables the feature even if it is enabled by default by > > the container > > > > An 'include-pattern' and 'exclude-pattern' can be specified to implement > > more exact filtering rules. Patterns are applied to the URL to rewrite, > > excludes are processed after includes > > > > An 'apply-to' is used to specify the comma separated list of mime-types > > which the rewriter should recognize and rewrite. By default the list is > > text/html,text/xml,application/xml (suggestions welcome here) > > > > <Optional feature="proxy-rewriter"> > > <Param name="include">DEFAULT</Param> > > <Param name="include-pattern">.*\/mystaticcontent\/.*</Param> > > <Param name="exclude-pattern">.*\/mynonstaticcontent\/.*</Param> > > <Param name="apply-to">text/html</Param> > > </Optional> > > > > This feature will not only impact the content generated when the gadget > > is rendered but is also used to control whether any content fetched through > > makeRequest, Preload and proxied URLs is also rewritten. > > > > It is probably also worthwhile mentioning how re-writing a URL to be > > proxied impacts the caching behavior of the content. Containers will cache > > content fetched through the proxy, in general containers are likely to favor > > a simpler expires/max-age style cache control policy rather than the more > > complicated to implement and more latency sensitive > > Last-Modified/If-Modified-Since which is the default mechanism Apache and > > other webservers use when serving static files. Containers are free to make > > policy decisions about how to alter the cache-control headers of content > > fetched through their proxy. > > > > A sample policy might look like: > > - Pragma : no-cache & Cache-Control : no-cache,no-store are always > > respected and this content will never be cached by the proxy > > - Expires and Cache-Control : max-age are always respected. If > > expiration is shorter than one day and the URL is a recognized static file > > type then expiration is forced to 1 day minimum > > - ETag & Last-Modified are stripped if Expires or Cache-Control is set > > or the URL is a recognized static file type. > > > > Such a policy is attempting to balance the needs of sophisticated users > > of real If-Modified requests and the default configuration of common static > > file serving configurations. > > > > Thoughts? > > > > -Louis > > > > > > * > > * > > > > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "OpenSocial and Gadgets Specification Discussion" group. > To post to this group, send email to > [EMAIL PROTECTED] > To unsubscribe from this group, send email to > [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en > -~----------~----~----~----~------~----~------~--~--- > >
