Major refactoring patch to incorporate several other open issues.
-----------------------------------------------------------------
Key: SHINDIG-118
URL: https://issues.apache.org/jira/browse/SHINDIG-118
Project: Shindig
Issue Type: Improvement
Reporter: Kevin Brown
Assignee: Kevin Brown
Attachments: ridiculously-large-refactoring.patch.txt
This patch provides significant architectural changes to the gadgets server.
Most of these changes were necessary to address new features and to prepare
the code base for coming improvements and rapid iteration as the gadget spec
evolves.
This patch addresses all of the following open issues:
- https://issues.apache.org/jira/browse/SHINDIG-21
- https://issues.apache.org/jira/browse/SHINDIG-23
- https://issues.apache.org/jira/browse/SHINDIG-36
- https://issues.apache.org/jira/browse/SHINDIG-49
- https://issues.apache.org/jira/browse/SHINDIG-50
- https://issues.apache.org/jira/browse/SHINDIG-79
- https://issues.apache.org/jira/browse/SHINDIG-80
- https://issues.apache.org/jira/browse/SHINDIG-83
Since the patch is so huge that I don't expect anyone to be able to really go
through it thoroughly, I've written up a summary of what's changed.
If you haven't yet needed to implement your own CrossServletState and various
interfaces, you can go ahead and just start using this now.
If you HAVE implemented your own CrossServletState or other interfaces, you
might have some conflicts. Most of these should be minor. I'd be more than
happy to help you integrate these changes.
Since this is such a large architectural change, it really needs some thorough
feedback before I'm going to even consider committing it. Please speak up if
you object to anything I've done here.
Improvements:
- Full gadget browser based caching (with room for additional server-side
caching via filters)
* Gadgets with no __UP or __MODULE hangman substitutions can be cached
indefinitely as long as the content of the spec doesn't change. User prefs now
get passed on the content hash.
* Gadgets that do have __UP or __MODULE hangman substitutions will still be
cached, but a change in a user pref value necessitates a change in the
gadget's iframe url.
* Pref specs are now passed to the client rather than pref values. Values are
always extracted from the url parameters.
- Modularization of feature javascript libraries for optimal performance
* passing &libs behavior is largerly unchanged, except now any libs not
mentioned will be inlined
* This allows sites to cache the most commonly used libs as a single file
entry,
- Type URL javascript files will now be inlined with other libraries, allowing
for significant latency improvements.
- Improvements to JSON RPC interface
* Now capable of returning extending view and meta data information, allowing
consumers to get access to virtually all pieces of the gadget spec easily.
- Much improved test coverage
* Over 50 new test cases (now over 160 total)
* At least one test for every non-trivial public class in gadgets and
gadgets.spec; coverage in gadgets.http is still weak, but improved.
* Virtually all spec rules checked explicitly
- Easier customization
* Most implementation details can now be overridden with your own
implementation
- Simplification
* Smaller classes
* Removed lots of redundant boiler plate code and refactored into utility
methods.
- Improved documentation
* Virtually every non-trivial public function / class is documented.
- Full support for all canonical spec fields and most extended spec, including
substitutions.
- Laying the groundwork for some significant security improvements. Details to
be announced separately since this is potentially a sensitive topic for some
existing containers.
Major architectural changes:
- GadgetServer
* Radically simplified. Spec & Message bundle retrieval is now always done
serially, since before they were just blocking other threads anyway. Only
features that do real work will be run under the current model.
- GadgetDataCache / RemoteContentFetcher
* Re-worked as a unified, task-specific retrieval interfaces. This allows
integrators to insert their own intermediate layers (such as distributed
caches) wherever and however they want rather than relying on the check / fetch
/ store behavior baked into the current implementation. This makes it much
easier to integrate Shindig in sites that use different retrieval models, such
as storage of gadget specs to a local file system or "push" rather than "pull"
models for gadget submission.
- GadgetFeature
* Since most features are now run serially, functional requirements for this
class were reduced, and the class has been simplified significantly.
- GadgetSpec, GadgetView, Gadget, ParsedGadget
* Converted to a set of small, focused classes that each address specific spec
elements, such as module prefs or views.
* Self parsing, self substiting, and consistent interfaces for all element
objects
* included in org.apache.shindig.gadgets.spec package
- ProcessingOptions, GadgetContext
* Unified into a single abstract context object that is used consistently
throughout all the code now.
New classes:
DataFetcher<T> (replaces GadgetDataCache<T> and works in conjunction with
RemoteContentFetcher to retrieve spec / message bundle data)
GadgetSpecFetcher (standard implementation of DataFetcher<GadgetSpec>; can be
replaced by custom implementations if desired)
MessageBundleFetcher (standard implementation of DataFetcher<MessageBundle>;
can be replaced)
spec.GadgetSpec (represents a <Module>)
spec.ModulePrefs (represents Module.ModulePrefs)
spec.UserPref (Module.UserPref)
spec.View (Module.Content...with some caveats, which is why we don't call it
Content)
spec.Feature (Module.ModulePrefs.Require + Module.ModulePrefs.Optional)
spec.LocaleSpec (Module.ModulePrefs.Locale; named to not conflict with
java.util.Locale)
spec.Icon (Module.ModulePrefs.Icon)
spec.MessageBundle (represents a <messagebundle>)
spec.SpecParserException (moved from gadgets)
http.RenderingRequest (handles most of the PageRenderingServlet's tasks, but
with member variables instead of trying to track a half dozen parameters)
http.HttpGadgetContext (implements GadgetContext and replaces
HttpProcessingOptions)
http.HttpUtil (utility classes for http)
http.JsonRpcGadgetContext (implements GadgetContext and replaces JsonRpcGadget
/ JsonRpcContext)
Removed Classes:
GadgetDataCache (replaced by DataFetcher)
GadgetSpec (moved / refactored in gadgets.spec package)
SpecParserException (moved to gadgets.spec)
GadgetSpecParser (behavior now built into gadgets.spec.* classes)
GadgetView (functionality rolled into Gadget and / or GadgetSpec)
MessageBundle (moved to gadgets.spec)
MessageBundleParser (baked into spec.MessageBundle)
MessageBundleSubstituter (baked into gadgets.spec classes)
ModuleSubstituter (it was only one static substitution, and there won't likely
ever be any new ones)
ProcessingOptions (rolled into GadgetContext)
http.BasicHttpContext (appears to have been unused)
http.HttpProcessingOptions (replaced by HttpGadgetContext)
http.JsonRpcContext (replaced by JsonRpcGadgetContext)
http.JsonRpcGadget (replaced by JsonRpcGadgetContext)
http.JsonRpcProcessingOptions (replaced by JsonRpcGadgetContext)
Most classes that were neither removed nor added were probably altered slightly
to take into account the new interfaces, but for the most part they're
unchanged.
Since this is such a sweeping change, I need feedback from as many people as
possible. Please speak up if you have any objections, suggestions, or
improvements. I'd like to get this committed sometime in the next week.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
