[jira] Commented: (SHINDIG-816) Stax based parser for GadgetSpec and MessageBundle

["Kevin Brown (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SHINDIG-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660976#action_12660976 ] 

Kevin Brown commented on SHINDIG-816:
-------------------------------------

This looks like a pretty solid improvement to me. I'm especially fond of creating a common interface for all spec objects, which is something I've had in the back of my head for a while now.

Some comments / suggestions

- Could you clarify "- works with the JDK 6 Stax parser and woodstox "? Does it work with JDK5 as well? We haven't done a survey on this issue recently, but back in February / March we agreed to keep everything compliant with JDK5. I'm personally in favor of a JDK6 move, but I don't know how many people that affects.

- We need to sort out the namespace issue for sure. What you have in the patch looks good to me, but nobody has chimed in on the thread you started on the spec list.

- We need the rawxml support for the development gadgets (http://osda.appspot.com/ and some others that I don't have urls for) and various plug ins. We should probably document this support explicitly.

- "Known bugs / deviations from the spec": 
    - Appending an empty ModulePrefs seems like a relatively easy solution to the first issue. It's a shame that ModulePrefs holds so much, because it's a really poorly thought out schema design.
    - The param_location thing needs to be addressed in spec. That's clearly an oversight.
    - OAuth items are spec issues, but I agree with your solutions
    - The arbitrary attributes issue is no longer a problem now that this is namespace-aware. We can safely assume that any 'extra' parameters will be appropriately namespaced, so shindig doesn't have to parse them. As long as a container can easily support whatever arbitrary attributes / elements that they want it's good.
    - Content element attributes are for 0.9. See: http://wiki.opensocial.org/index.php?title=Proxied_Content. It's probably worth establishing a convention (an annotation, perhaps?) identifying the stuff that's not a part of the latest spec (and possibly identifying stuff that's been deprecated in the spec, as the Preload element will be if data pipelining is implemented as is).



> Stax based parser for GadgetSpec and MessageBundle
> --------------------------------------------------
>
>                 Key: SHINDIG-816
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-816
>             Project: Shindig
>          Issue Type: Improvement
>          Components: Gadget Rendering Server (Java)
>    Affects Versions: 1.0.x-incubating
>            Reporter: Henning Schmiedehausen
>         Attachments: RELEASE-NOTES, svn-stax.patch
>
>
> This is a large patch which I don't expect to go in without some discussion. However, we have to start at some point. 
> As I wrote before (and those of you following my mails to the dev list probably know), I need some features that the current, DOM based parser for GadgetSpec and related to this, for MessageBundle, can not deliver. I need to reconstruct gadget specs from the objects, passing through other namespaced elements and a number of additional requirements which, in the end, led to a complete new implementation of the GadgetSpec parser using Stax. 
> The attached RELEASE-NOTES file describes in ample detail the problems that I have encountered and the quirks I discovered while dissecting the existing parser. 
> And, while it does not really matter with good caching, preliminary tests show that the parser is measurably faster than the old DOM parser. If it were possible to stream XML into it, there would be even more performance improvements.
> Given the fact, that we will soon see other namespaces in the gadget spec (the whole templating stuff), this should be much easier and more readable doable using this parser approach.
> A code review ist at http://codereview.appspot.com/11676

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.