You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Kevin Brown (JIRA)" <ji...@apache.org> on 2008/03/10 05:31:47 UTC
[jira] Created: (SHINDIG-118) Major refactoring patch to
incorporate several other open issues.
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.
[jira] Commented: (SHINDIG-118) Major refactoring patch to
incorporate several other open issues.
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577009#action_12577009 ]
Paul Lindner commented on SHINDIG-118:
--------------------------------------
This is going into the code base in one form or another, so why not tag or branch trunk and apply this?
If that's too radical, how about committing this to a branch so those who want to work with it can do so?
> 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.
[jira] Commented: (SHINDIG-118) Major refactoring patch to
incorporate several other open issues.
Posted by "Luciano Resende (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (SHINDIG-118) Major refactoring patch to
incorporate several other open issues.
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Brown updated SHINDIG-118:
--------------------------------
Attachment: ridiculously-large-refactoring.patch.txt
> 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.
[jira] Commented: (SHINDIG-118) Major refactoring patch to
incorporate several other open issues.
Posted by "Paul Lindner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577124#action_12577124 ]
Paul Lindner commented on SHINDIG-118:
--------------------------------------
I created a new tag as https://svn.apache.org/repos/asf/incubator/shindig/tags/shindig-20080310, so we should be able to proceed with this refactor in trunk.
> 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.
[jira] Commented: (SHINDIG-118) Major refactoring patch to
incorporate several other open issues.
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577109#action_12577109 ]
Kevin Brown commented on SHINDIG-118:
-------------------------------------
We could do that -- I'm not particularly familiar with SVN so I'm not sure what appropriate branching policy is. From what I remember of my CVS days, branch merging was painful. Any pointers?
> 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.
[jira] Commented: (SHINDIG-118) Major refactoring patch to
incorporate several other open issues.
Posted by "Santiago Gala (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577555#action_12577555 ]
Santiago Gala commented on SHINDIG-118:
---------------------------------------
If you still want to branch instead of tagging, using svnmerge.py ( http://www.orcaware.com/mailman/listinfo/svnmerge ) ensures that the merges between the trunk and the branch will be remembered. It is under contrib in subversion, it will be part of the main subversion in 1.5* releases.
I'm also traying to test git-svn to support more such advances techniques in the client side, see for instance ( http://github.com/sgala/apache-incubator-shindig/commits/master/ ) for a copy of shindig. Doing a git-svn import for apache projects is tricky due to some anti-DoS measures infrastructure is currently running, and I set up the authors file half way so most commit authors show just the svn id and not the whole name-email.
> 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.
[jira] Closed: (SHINDIG-118) Major refactoring patch to incorporate
several other open issues.
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Brown closed SHINDIG-118.
-------------------------------
Resolution: Fixed
Applied. Please open new issues if this patch causes any issues (other than those already mentioned in the patch notes).
> 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.