[
https://issues.apache.org/jira/browse/SHINDIG-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577112#action_12577112
]
Luciano Resende commented on SHINDIG-118:
-----------------------------------------
Trunk should be fine, we could advise other to checkout specific revision (e.g
prior to this change) in case they want old code. Branch/merge is painful.
> 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.
