On Thu, Aug 14, 2008 at 6:34 PM, Louis Ryan <[EMAIL PROTECTED]> wrote:
> Probably need some way to classify preloaders, some portion of these can be > executed in parallel with gadget rewriting as we do today. I thought about this, but I don't think it's worth the trouble initially. Even if a preloader can be run in parallel with some rewriters, there are other rewriters that will be using that preloaded data (if nothing else, the "final" rewriter which injects our javascript and wrapper document). Given that preloaders will necessarily be a lot slower than rewriters, it's probably not worth adding that level of complexity yet. > > > On Thu, Aug 14, 2008 at 5:47 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > Several new requirements are upon us, ranging from enhanced content > > rewriting (needed for optimization, with a good starting point outlined > by > > johnh recently) to proxied content (proposed by me and under discussion > on > > the spec list), to opensocial template processing, along with the desire > to > > eliminate a lot of long-standing cruft have converged on a need to clean > up > > the basic rendering pipeline. > > > > My basic proposal for achieving this clean up is as follows: > > > > Set up: > > - GadgetProcessor replaces GadgetServer. Responsible for normalizing > > manifest data (GadgetSpecFactory & MessageBundleFactory) and converting > to > > an intermediate state. > > > > - GadgetRenderer deals with rendering only (metadata is handled > > separately). > > Creation parameters are: > > * The GadgetProcessor singleton > > * Rewriter(s) (and other serial processes); held in some new container > > for rewriters (see John's earlier email) > > * Preloader(s) (and other parallel processes); held in some new > container > > for preloaders (unifies existing Preload processing and social data > > preloading required for template processing as well as general > optimization > > as discussed by Adam Winer). > > > > Processing: > > - Servlet receives request (GadgetRenderingServlet unchanged) > > - Request is disassembled into components and handed to GadgetRenderer > > (existing GadgetContext, with some possible enhancements) > > * Invokes GadgetProcessor to get basic data for the Gadget > > * Executes preloaders in parallel, block until all are complete. > > * Passes processed gadget through Rewriters (in registered order) > > * Returns final output markup > > > > Initially, the Rewriters won't do much (just basic content-rewrite > stuff), > > though one notable difference in behavior is that even basic markup that > we > > add, such as injected scripts and the standard markup wrapper for > type=html > > will become a rewriter. Variable substitution will happen at this level > as > > well, though the variable substituter needs to be somewhat more robust > than > > other rewriters because it needs to be reused in metadata processing. > > > > This shouldn't affect any public interfaces, so even though it's an > > extensive internal cleanup, it's a relatively safe change. > > >
