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.

Reply via email to