Some notes on Modules Re: Rome2

[Robert (kebernet) Cooper]

There are a hand full of things I would like to talk about briefly re:
Rome2 (Rome 1.5?)

One of the things I see as problematic right now is that there are
some common cases on the internet that are very hard to support with
the current modules system, or the last proposals. I would like to
outline some changes that I think would be good to have.

I know Alejandro has a proposal from a looong time ago here.
http://wiki.java.net/bin/view/Javawsxml/ROME2Proposal2

There are a few things I would really like to be able to do that
aren't covered by this, though.


First lifecycle:

Currently modules are simply registered by their exposed Namespace
string. This works generally, but makes some cases hard. For example,
the Google Data API types entry's using the standard <category> tag:

<category scheme="http://schemas.google.com/g/2005#kind"
term="http://schemas.google.com/g/2005#event"/>

There are also a number of specs that are based not on an element
space, but an attribute namespace on specific elements element. For
example, Google Reader:

<source gr:stream-id="feed/http://scala-blogs.org/feeds/posts/default">

Rather than have a module parser that has to crawl around the JDOM
tree -- assuming we aren't going to switch to StAX/Pull based parser,
which I think would be preferable. I think the
ModuleParser/ModuleGenerator should register themselves, rather than
expose an interface. This would look something like:

public interface ModuleParserProvider<T extends Module> {

      //Initializes the ParserContext with the defaults for the module.
      void init(ParserContext context);

}

public interface EntryModuleParser<T extends Module> {

     /** @return Whether the element was handled by the module parser or not */
      boolean parseModule(T module, Element e); //(Event e in ROME2?)
}

public interface FeedModuleParser<T extends Module> {

     /** @return Whether the element was handled by the module parser or not */
      boolean parseModule(T module, Element e); //(Event e?)
}

pulic interface ModuleFactory<T extends Module> {

      public T create();

}

public class ParserContext {

      public void setFactory(ModuleParser parser, ModuleFactory factory);
      public void registerHandler(ModuleParser parser, String
namespace, String nodeName);
      public RomeIO getCurrentRomeIO(); // should be based on a
ThreadLocal<RomeIO>

}

The lifecycle for a parser for the Google Calendar spec might then be:

public class GCalParser implements EntryModuleParser<GCalEvent>,
ModuleParserProvider<GCalEvent> {

    public void init(ParserContext context){
        context.setFactory(GCalParser.class, new GCalEventFactory());
        context.registerHandler( this, "http://www.w3.org/2005/Atom",
"category");
        context.registerHandler( new ColorParser(),
"http://schemas.google.com/gCal/2005#", "color"); // indicates this is
for the full namespace.
    }

    public boolean parseModule(GCalEvent event, Element e){
        return e.getAttributeValue("scheme") != null &&
e.getAttributeValue("scheme").equals("http://schemas.google.com/g/2005#kind")
                  && e.getAttributeValue("term") != null &&
e.getAttributeValue("term").equals("http://schemas.google.com/g/2005#event");
        // returns True, meaning that the GCalEvent module will now be
associate with the parsed object (entry) and that it should not fall
through
        // to any other parsers (here, the default parser for <category>.
    }

   private static class ColorParser implemements ModuleParser<GCalEvent>{
       boolean parseModule(GCalEvent module, Element e){
              module.setColor(e.getText() );
      }
   }
}

Here you can see a few things. First, You can implement a Parser and
ParserProvider with the same class if you want a parser that works,
generallly, like the ROME1 parsers. This will make code porting fairly
easy. Secondly, if you want to avoid the GIANT conditionals we
currently have, you can provide a separate parser for each element
name (here the ColorParser). Modules should register their default
factory providers, but these should be clobberable before parsing by
dependency injection frameworks, such as:

RomeIO io = new RomeIO();
io.getParserContext().setFactory(GCalParser.class, new
MyJPAGCalFactory( myEntityManagerFactory ) );

ModuleParserProviders should be discovered using the standard service
provider methodology
(http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service
Provider) rather than various props files, should be thread safe.
ModuleParser implementations don't have to be thread safe, unless
implemented by the same class as the Provider (As above). This means
that each new instantiation of RomeIO (or similar) should create a new
ParserContext and init() on the ModuleParserProviders, but the
providers themselves can be discovered and instantiated once. Again,
since the registration and parser instantiation steps are separate
here, that means module authors can either create since instances of
Parsers inside their provider class if they are thread safe, or
instantiate new once for each init() call. Since the RomeIO class will
be thread local on init(), modules could then use it to parse nested
feeds or reach out to the network for links (in the case of Comments
in all the GDATA feeds that contain nested Atom feeds). This allows us
to get around all the places where we are currently addressing the
feed parser classes directly.




--
:Robert "kebernet" Cooper
::kebernet@...
Alice's cleartext
Charlie is the attacker
Bob signs and encrypts
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Robert (kebernet) Cooper]

On this topic, I have a basic implementation now for what I would call
"Rome 1.5" working.

My question is, should I make a new tree in CVS, or do we want to
start a Rome2 project on Java.net or Kenai and change SCM systems?

On Mon, Mar 9, 2009 at 1:58 PM, Robert kebernet Cooper
<kebernet@...> wrote:

> There are a hand full of things I would like to talk about briefly re:
> Rome2 (Rome 1.5?)
>
> One of the things I see as problematic right now is that there are
> some common cases on the internet that are very hard to support with
> the current modules system, or the last proposals. I would like to
> outline some changes that I think would be good to have.
>
> I know Alejandro has a proposal from a looong time ago here.
> http://wiki.java.net/bin/view/Javawsxml/ROME2Proposal2
>
> There are a few things I would really like to be able to do that
> aren't covered by this, though.
>
>
> First lifecycle:
>
> Currently modules are simply registered by their exposed Namespace
> string. This works generally, but makes some cases hard. For example,
> the Google Data API types entry's using the standard <category> tag:
>
> <category scheme="http://schemas.google.com/g/2005#kind"
> term="http://schemas.google.com/g/2005#event"/>
>
> There are also a number of specs that are based not on an element
> space, but an attribute namespace on specific elements element. For
> example, Google Reader:
>
> <source gr:stream-id="feed/http://scala-blogs.org/feeds/posts/default">
>
> Rather than have a module parser that has to crawl around the JDOM
> tree -- assuming we aren't going to switch to StAX/Pull based parser,
> which I think would be preferable. I think the
> ModuleParser/ModuleGenerator should register themselves, rather than
> expose an interface. This would look something like:
>
> public interface ModuleParserProvider<T extends Module> {
>
>      //Initializes the ParserContext with the defaults for the module.
>      void init(ParserContext context);
>
> }
>
> public interface EntryModuleParser<T extends Module> {
>
>     /** @return Whether the element was handled by the module parser or not */
>      boolean parseModule(T module, Element e); //(Event e in ROME2?)
> }
>
> public interface FeedModuleParser<T extends Module> {
>
>     /** @return Whether the element was handled by the module parser or not */
>      boolean parseModule(T module, Element e); //(Event e?)
> }
>
> pulic interface ModuleFactory<T extends Module> {
>
>      public T create();
>
> }
>
> public class ParserContext {
>
>      public void setFactory(ModuleParser parser, ModuleFactory factory);
>      public void registerHandler(ModuleParser parser, String
> namespace, String nodeName);
>      public RomeIO getCurrentRomeIO(); // should be based on a
> ThreadLocal<RomeIO>
>
> }
>
> The lifecycle for a parser for the Google Calendar spec might then be:
>
> public class GCalParser implements EntryModuleParser<GCalEvent>,
> ModuleParserProvider<GCalEvent> {
>
>    public void init(ParserContext context){
>        context.setFactory(GCalParser.class, new GCalEventFactory());
>        context.registerHandler( this, "http://www.w3.org/2005/Atom",
> "category");
>        context.registerHandler( new ColorParser(),
> "http://schemas.google.com/gCal/2005#", "color"); // indicates this is
> for the full namespace.
>    }
>
>    public boolean parseModule(GCalEvent event, Element e){
>        return e.getAttributeValue("scheme") != null &&
> e.getAttributeValue("scheme").equals("http://schemas.google.com/g/2005#kind")
>                  && e.getAttributeValue("term") != null &&
> e.getAttributeValue("term").equals("http://schemas.google.com/g/2005#event");
>        // returns True, meaning that the GCalEvent module will now be
> associate with the parsed object (entry) and that it should not fall
> through
>        // to any other parsers (here, the default parser for <category>.
>    }
>
>   private static class ColorParser implemements ModuleParser<GCalEvent>{
>       boolean parseModule(GCalEvent module, Element e){
>              module.setColor(e.getText() );
>      }
>   }
> }
>
> Here you can see a few things. First, You can implement a Parser and
> ParserProvider with the same class if you want a parser that works,
> generallly, like the ROME1 parsers. This will make code porting fairly
> easy. Secondly, if you want to avoid the GIANT conditionals we
> currently have, you can provide a separate parser for each element
> name (here the ColorParser). Modules should register their default
> factory providers, but these should be clobberable before parsing by
> dependency injection frameworks, such as:
>
> RomeIO io = new RomeIO();
> io.getParserContext().setFactory(GCalParser.class, new
> MyJPAGCalFactory( myEntityManagerFactory ) );
>
> ModuleParserProviders should be discovered using the standard service
> provider methodology
> (http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service
> Provider) rather than various props files, should be thread safe.
> ModuleParser implementations don't have to be thread safe, unless
> implemented by the same class as the Provider (As above). This means
> that each new instantiation of RomeIO (or similar) should create a new
> ParserContext and init() on the ModuleParserProviders, but the
> providers themselves can be discovered and instantiated once. Again,
> since the registration and parser instantiation steps are separate
> here, that means module authors can either create since instances of
> Parsers inside their provider class if they are thread safe, or
> instantiate new once for each init() call. Since the RomeIO class will
> be thread local on init(), modules could then use it to parse nested
> feeds or reach out to the network for links (in the case of Comments
> in all the GDATA feeds that contain nested Atom feeds). This allows us
> to get around all the places where we are currently addressing the
> feed parser classes directly.
>
>
>
>
> --
> :Robert "kebernet" Cooper
> ::kebernet@...
> Alice's cleartext
> Charlie is the attacker
> Bob signs and encrypts
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8
>

--
:Robert "kebernet" Cooper
::kebernet@...
Alice's cleartext
Charlie is the attacker
Bob signs and encrypts
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Alejandro Abdelnur-2]

Robert,

You've spelled out very good issues.

Attached you'll find my prototype (somehow evolved from the proposal) which, I think, addresses most if not all of your concerns. javadocs are not complete, testcases are sparse, but by looking at them you'll get an idea of how things work.

The prototype does away with Synd* and it is just for Atom, no RSS support.

For StAX parsing support ... I've broken the parsing in 2 layers, one is the XML parsing and the other is the Atom parsing. Atom parsing is done on JDOM elements. XML parsing is done using either JDOM, StAX but it bubbles up always JDOM. The current XML parsing is done using JDOM, I have some code that does the StAX parsing, I could get it to fully work if people like this whole approach.

I've used maven 2 and there are 2 modules, core (ROME2 proper) and bag (a BagExtension for any element/attribute).

These days I don't have much time to work on this but I hope that this helps people going with ROME2.

Regarding your question about project and SCM, I would go for creating a new project, ROME2, in java.net using SVN, and as ROME using Apache license.

Cheers.

Alejandro

On Tue, Mar 10, 2009 at 7:31 AM, Robert kebernet Cooper <kebernet@...> wrote:

On this topic, I have a basic implementation now for what I would call
"Rome 1.5" working.

My question is, should I make a new tree in CVS, or do we want to
start a Rome2 project on Java.net or Kenai and change SCM systems?

On Mon, Mar 9, 2009 at 1:58 PM, Robert kebernet Cooper
<kebernet@...> wrote:
> There are a hand full of things I would like to talk about briefly re:
> Rome2 (Rome 1.5?)
>
> One of the things I see as problematic right now is that there are
> some common cases on the internet that are very hard to support with
> the current modules system, or the last proposals. I would like to
> outline some changes that I think would be good to have.
>
> I know Alejandro has a proposal from a looong time ago here.
> http://wiki.java.net/bin/view/Javawsxml/ROME2Proposal2
>
> There are a few things I would really like to be able to do that
> aren't covered by this, though.
>
>
> First lifecycle:
>
> Currently modules are simply registered by their exposed Namespace
> string. This works generally, but makes some cases hard. For example,
> the Google Data API types entry's using the standard <category> tag:
>
> <category scheme="http://schemas.google.com/g/2005#kind"
> term="http://schemas.google.com/g/2005#event"/>
>
> There are also a number of specs that are based not on an element
> space, but an attribute namespace on specific elements element. For
> example, Google Reader:
>
> <source gr:stream-id="feed/http://scala-blogs.org/feeds/posts/default">
>
> Rather than have a module parser that has to crawl around the JDOM
> tree -- assuming we aren't going to switch to StAX/Pull based parser,
> which I think would be preferable. I think the
> ModuleParser/ModuleGenerator should register themselves, rather than
> expose an interface. This would look something like:
>
> public interface ModuleParserProvider<T extends Module> {
>
>      //Initializes the ParserContext with the defaults for the module.
>      void init(ParserContext context);
>
> }
>
> public interface EntryModuleParser<T extends Module> {
>
>     /** @return Whether the element was handled by the module parser or not */
>      boolean parseModule(T module, Element e); //(Event e in ROME2?)
> }
>
> public interface FeedModuleParser<T extends Module> {
>
>     /** @return Whether the element was handled by the module parser or not */
>      boolean parseModule(T module, Element e); //(Event e?)
> }
>
> pulic interface ModuleFactory<T extends Module> {
>
>      public T create();
>
> }
>
> public class ParserContext {
>
>      public void setFactory(ModuleParser parser, ModuleFactory factory);
>      public void registerHandler(ModuleParser parser, String
> namespace, String nodeName);
>      public RomeIO getCurrentRomeIO(); // should be based on a
> ThreadLocal<RomeIO>
>
> }
>
> The lifecycle for a parser for the Google Calendar spec might then be:
>
> public class GCalParser implements EntryModuleParser<GCalEvent>,
> ModuleParserProvider<GCalEvent> {
>
>    public void init(ParserContext context){
>        context.setFactory(GCalParser.class, new GCalEventFactory());
>        context.registerHandler( this, "http://www.w3.org/2005/Atom",
> "category");
>        context.registerHandler( new ColorParser(),
> "http://schemas.google.com/gCal/2005#", "color"); // indicates this is
> for the full namespace.
>    }
>
>    public boolean parseModule(GCalEvent event, Element e){
>        return e.getAttributeValue("scheme") != null &&
> e.getAttributeValue("scheme").equals("http://schemas.google.com/g/2005#kind")
>                  && e.getAttributeValue("term") != null &&
> e.getAttributeValue("term").equals("http://schemas.google.com/g/2005#event");
>        // returns True, meaning that the GCalEvent module will now be
> associate with the parsed object (entry) and that it should not fall
> through
>        // to any other parsers (here, the default parser for <category>.
>    }
>
>   private static class ColorParser implemements ModuleParser<GCalEvent>{
>       boolean parseModule(GCalEvent module, Element e){
>              module.setColor(e.getText() );
>      }
>   }
> }
>
> Here you can see a few things. First, You can implement a Parser and
> ParserProvider with the same class if you want a parser that works,
> generallly, like the ROME1 parsers. This will make code porting fairly
> easy. Secondly, if you want to avoid the GIANT conditionals we
> currently have, you can provide a separate parser for each element
> name (here the ColorParser). Modules should register their default
> factory providers, but these should be clobberable before parsing by
> dependency injection frameworks, such as:
>
> RomeIO io = new RomeIO();
> io.getParserContext().setFactory(GCalParser.class, new
> MyJPAGCalFactory( myEntityManagerFactory ) );
>
> ModuleParserProviders should be discovered using the standard service
> provider methodology
> (http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service
> Provider) rather than various props files, should be thread safe.
> ModuleParser implementations don't have to be thread safe, unless
> implemented by the same class as the Provider (As above). This means
> that each new instantiation of RomeIO (or similar) should create a new
> ParserContext and init() on the ModuleParserProviders, but the
> providers themselves can be discovered and instantiated once. Again,
> since the registration and parser instantiation steps are separate
> here, that means module authors can either create since instances of
> Parsers inside their provider class if they are thread safe, or
> instantiate new once for each init() call. Since the RomeIO class will
> be thread local on init(), modules could then use it to parse nested
> feeds or reach out to the network for links (in the case of Comments
> in all the GDATA feeds that contain nested Atom feeds). This allows us
> to get around all the places where we are currently addressing the
> feed parser classes directly.
>
>
>
>
> --
> :Robert "kebernet" Cooper
> ::kebernet@...
> Alice's cleartext
> Charlie is the attacker
> Bob signs and encrypts
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8
>



--
:Robert "kebernet" Cooper
::kebernet@...
Alice's cleartext
Charlie is the attacker
Bob signs and encrypts
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Robert (kebernet) Cooper]

I put in a request for https://rome2.dev.java.net/. I will add
everyone when the approval comes through. I will start checking in
your and my prototype code later this afternoon.

On Tue, Mar 10, 2009 at 6:25 AM, Alejandro Abdelnur <tucu00@...> wrote:

> Robert,
>
> You've spelled out very good issues.
>
> Attached you'll find my prototype (somehow evolved from the proposal) which,
> I think, addresses most if not all of your concerns. javadocs are not
> complete, testcases are sparse, but by looking at them you'll get an idea of
> how things work.
>
> The prototype does away with Synd* and it is just for Atom, no RSS support.
>
> For StAX parsing support ... I've broken the parsing in 2 layers, one is the
> XML parsing and the other is the Atom parsing. Atom parsing is done on JDOM
> elements. XML parsing is done using either JDOM, StAX but it bubbles up
> always JDOM. The current XML parsing is done using JDOM, I have some code
> that does the StAX parsing, I could get it to fully work if people like this
> whole approach.
>
> I've used maven 2 and there are 2 modules, core (ROME2 proper) and bag (a
> BagExtension for any element/attribute).
>
> These days I don't have much time to work on this but I hope that this helps
> people going with ROME2.
>
> Regarding your question about project and SCM, I would go for creating a new
> project, ROME2, in java.net using SVN, and as ROME using Apache license.
>
> Cheers.
>
> Alejandro
>
>
>
>
>
> On Tue, Mar 10, 2009 at 7:31 AM, Robert kebernet Cooper <kebernet@...>
> wrote:
>>
>> On this topic, I have a basic implementation now for what I would call
>> "Rome 1.5" working.
>>
>> My question is, should I make a new tree in CVS, or do we want to
>> start a Rome2 project on Java.net or Kenai and change SCM systems?
>>
>> On Mon, Mar 9, 2009 at 1:58 PM, Robert kebernet Cooper
>> <kebernet@...> wrote:
>> > There are a hand full of things I would like to talk about briefly re:
>> > Rome2 (Rome 1.5?)
>> >
>> > One of the things I see as problematic right now is that there are
>> > some common cases on the internet that are very hard to support with
>> > the current modules system, or the last proposals. I would like to
>> > outline some changes that I think would be good to have.
>> >
>> > I know Alejandro has a proposal from a looong time ago here.
>> > http://wiki.java.net/bin/view/Javawsxml/ROME2Proposal2
>> >
>> > There are a few things I would really like to be able to do that
>> > aren't covered by this, though.
>> >
>> >
>> > First lifecycle:
>> >
>> > Currently modules are simply registered by their exposed Namespace
>> > string. This works generally, but makes some cases hard. For example,
>> > the Google Data API types entry's using the standard <category> tag:
>> >
>> > <category scheme="http://schemas.google.com/g/2005#kind"
>> > term="http://schemas.google.com/g/2005#event"/>
>> >
>> > There are also a number of specs that are based not on an element
>> > space, but an attribute namespace on specific elements element. For
>> > example, Google Reader:
>> >
>> > <source gr:stream-id="feed/http://scala-blogs.org/feeds/posts/default">
>> >
>> > Rather than have a module parser that has to crawl around the JDOM
>> > tree -- assuming we aren't going to switch to StAX/Pull based parser,
>> > which I think would be preferable. I think the
>> > ModuleParser/ModuleGenerator should register themselves, rather than
>> > expose an interface. This would look something like:
>> >
>> > public interface ModuleParserProvider<T extends Module> {
>> >
>> >      //Initializes the ParserContext with the defaults for the module.
>> >      void init(ParserContext context);
>> >
>> > }
>> >
>> > public interface EntryModuleParser<T extends Module> {
>> >
>> >     /** @return Whether the element was handled by the module parser or
>> > not */
>> >      boolean parseModule(T module, Element e); //(Event e in ROME2?)
>> > }
>> >
>> > public interface FeedModuleParser<T extends Module> {
>> >
>> >     /** @return Whether the element was handled by the module parser or
>> > not */
>> >      boolean parseModule(T module, Element e); //(Event e?)
>> > }
>> >
>> > pulic interface ModuleFactory<T extends Module> {
>> >
>> >      public T create();
>> >
>> > }
>> >
>> > public class ParserContext {
>> >
>> >      public void setFactory(ModuleParser parser, ModuleFactory factory);
>> >      public void registerHandler(ModuleParser parser, String
>> > namespace, String nodeName);
>> >      public RomeIO getCurrentRomeIO(); // should be based on a
>> > ThreadLocal<RomeIO>
>> >
>> > }
>> >
>> > The lifecycle for a parser for the Google Calendar spec might then be:
>> >
>> > public class GCalParser implements EntryModuleParser<GCalEvent>,
>> > ModuleParserProvider<GCalEvent> {
>> >
>> >    public void init(ParserContext context){
>> >        context.setFactory(GCalParser.class, new GCalEventFactory());
>> >        context.registerHandler( this, "http://www.w3.org/2005/Atom",
>> > "category");
>> >        context.registerHandler( new ColorParser(),
>> > "http://schemas.google.com/gCal/2005#", "color"); // indicates this is
>> > for the full namespace.
>> >    }
>> >
>> >    public boolean parseModule(GCalEvent event, Element e){
>> >        return e.getAttributeValue("scheme") != null &&
>> >
>> > e.getAttributeValue("scheme").equals("http://schemas.google.com/g/2005#kind")
>> >                  && e.getAttributeValue("term") != null &&
>> >
>> > e.getAttributeValue("term").equals("http://schemas.google.com/g/2005#event");
>> >        // returns True, meaning that the GCalEvent module will now be
>> > associate with the parsed object (entry) and that it should not fall
>> > through
>> >        // to any other parsers (here, the default parser for <category>.
>> >    }
>> >
>> >   private static class ColorParser implemements ModuleParser<GCalEvent>{
>> >       boolean parseModule(GCalEvent module, Element e){
>> >              module.setColor(e.getText() );
>> >      }
>> >   }
>> > }
>> >
>> > Here you can see a few things. First, You can implement a Parser and
>> > ParserProvider with the same class if you want a parser that works,
>> > generallly, like the ROME1 parsers. This will make code porting fairly
>> > easy. Secondly, if you want to avoid the GIANT conditionals we
>> > currently have, you can provide a separate parser for each element
>> > name (here the ColorParser). Modules should register their default
>> > factory providers, but these should be clobberable before parsing by
>> > dependency injection frameworks, such as:
>> >
>> > RomeIO io = new RomeIO();
>> > io.getParserContext().setFactory(GCalParser.class, new
>> > MyJPAGCalFactory( myEntityManagerFactory ) );
>> >
>> > ModuleParserProviders should be discovered using the standard service
>> > provider methodology
>> > (http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service
>> > Provider) rather than various props files, should be thread safe.
>> > ModuleParser implementations don't have to be thread safe, unless
>> > implemented by the same class as the Provider (As above). This means
>> > that each new instantiation of RomeIO (or similar) should create a new
>> > ParserContext and init() on the ModuleParserProviders, but the
>> > providers themselves can be discovered and instantiated once. Again,
>> > since the registration and parser instantiation steps are separate
>> > here, that means module authors can either create since instances of
>> > Parsers inside their provider class if they are thread safe, or
>> > instantiate new once for each init() call. Since the RomeIO class will
>> > be thread local on init(), modules could then use it to parse nested
>> > feeds or reach out to the network for links (in the case of Comments
>> > in all the GDATA feeds that contain nested Atom feeds). This allows us
>> > to get around all the places where we are currently addressing the
>> > feed parser classes directly.
>> >
>> >
>> >
>> >
>> > --
>> > :Robert "kebernet" Cooper
>> > ::kebernet@...
>> > Alice's cleartext
>> > Charlie is the attacker
>> > Bob signs and encrypts
>> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8
>> >
>>
>>
>>
>> --
>> :Robert "kebernet" Cooper
>> ::kebernet@...
>> Alice's cleartext
>> Charlie is the attacker
>> Bob signs and encrypts
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
:Robert "kebernet" Cooper
::kebernet@...
Alice's cleartext
Charlie is the attacker
Bob signs and encrypts
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dave-401]

On Tue, Mar 10, 2009 at 10:44 AM, Robert kebernet Cooper
<kebernet@...> wrote:
> I put in a request for https://rome2.dev.java.net/. I will add
> everyone when the approval comes through. I will start checking in
> your and my prototype code later this afternoon.

Why not Google Code?

Java.net is double-dog slow these days and even Sun is trying to
escape from it (see also: Kenai).

- Dave

> On Tue, Mar 10, 2009 at 6:25 AM, Alejandro Abdelnur <tucu00@...> wrote:
>> Robert,
>>
>> You've spelled out very good issues.
>>
>> Attached you'll find my prototype (somehow evolved from the proposal) which,
>> I think, addresses most if not all of your concerns. javadocs are not
>> complete, testcases are sparse, but by looking at them you'll get an idea of
>> how things work.
>>
>> The prototype does away with Synd* and it is just for Atom, no RSS support.
>>
>> For StAX parsing support ... I've broken the parsing in 2 layers, one is the
>> XML parsing and the other is the Atom parsing. Atom parsing is done on JDOM
>> elements. XML parsing is done using either JDOM, StAX but it bubbles up
>> always JDOM. The current XML parsing is done using JDOM, I have some code
>> that does the StAX parsing, I could get it to fully work if people like this
>> whole approach.
>>
>> I've used maven 2 and there are 2 modules, core (ROME2 proper) and bag (a
>> BagExtension for any element/attribute).
>>
>> These days I don't have much time to work on this but I hope that this helps
>> people going with ROME2.
>>
>> Regarding your question about project and SCM, I would go for creating a new
>> project, ROME2, in java.net using SVN, and as ROME using Apache license.
>>
>> Cheers.
>>
>> Alejandro
>>
>>
>>
>>
>>
>> On Tue, Mar 10, 2009 at 7:31 AM, Robert kebernet Cooper <kebernet@...>
>> wrote:
>>>
>>> On this topic, I have a basic implementation now for what I would call
>>> "Rome 1.5" working.
>>>
>>> My question is, should I make a new tree in CVS, or do we want to
>>> start a Rome2 project on Java.net or Kenai and change SCM systems?
>>>
>>> On Mon, Mar 9, 2009 at 1:58 PM, Robert kebernet Cooper
>>> <kebernet@...> wrote:
>>> > There are a hand full of things I would like to talk about briefly re:
>>> > Rome2 (Rome 1.5?)
>>> >
>>> > One of the things I see as problematic right now is that there are
>>> > some common cases on the internet that are very hard to support with
>>> > the current modules system, or the last proposals. I would like to
>>> > outline some changes that I think would be good to have.
>>> >
>>> > I know Alejandro has a proposal from a looong time ago here.
>>> > http://wiki.java.net/bin/view/Javawsxml/ROME2Proposal2
>>> >
>>> > There are a few things I would really like to be able to do that
>>> > aren't covered by this, though.
>>> >
>>> >
>>> > First lifecycle:
>>> >
>>> > Currently modules are simply registered by their exposed Namespace
>>> > string. This works generally, but makes some cases hard. For example,
>>> > the Google Data API types entry's using the standard <category> tag:
>>> >
>>> > <category scheme="http://schemas.google.com/g/2005#kind"
>>> > term="http://schemas.google.com/g/2005#event"/>
>>> >
>>> > There are also a number of specs that are based not on an element
>>> > space, but an attribute namespace on specific elements element. For
>>> > example, Google Reader:
>>> >
>>> > <source gr:stream-id="feed/http://scala-blogs.org/feeds/posts/default">
>>> >
>>> > Rather than have a module parser that has to crawl around the JDOM
>>> > tree -- assuming we aren't going to switch to StAX/Pull based parser,
>>> > which I think would be preferable. I think the
>>> > ModuleParser/ModuleGenerator should register themselves, rather than
>>> > expose an interface. This would look something like:
>>> >
>>> > public interface ModuleParserProvider<T extends Module> {
>>> >
>>> >      //Initializes the ParserContext with the defaults for the module.
>>> >      void init(ParserContext context);
>>> >
>>> > }
>>> >
>>> > public interface EntryModuleParser<T extends Module> {
>>> >
>>> >     /** @return Whether the element was handled by the module parser or
>>> > not */
>>> >      boolean parseModule(T module, Element e); //(Event e in ROME2?)
>>> > }
>>> >
>>> > public interface FeedModuleParser<T extends Module> {
>>> >
>>> >     /** @return Whether the element was handled by the module parser or
>>> > not */
>>> >      boolean parseModule(T module, Element e); //(Event e?)
>>> > }
>>> >
>>> > pulic interface ModuleFactory<T extends Module> {
>>> >
>>> >      public T create();
>>> >
>>> > }
>>> >
>>> > public class ParserContext {
>>> >
>>> >      public void setFactory(ModuleParser parser, ModuleFactory factory);
>>> >      public void registerHandler(ModuleParser parser, String
>>> > namespace, String nodeName);
>>> >      public RomeIO getCurrentRomeIO(); // should be based on a
>>> > ThreadLocal<RomeIO>
>>> >
>>> > }
>>> >
>>> > The lifecycle for a parser for the Google Calendar spec might then be:
>>> >
>>> > public class GCalParser implements EntryModuleParser<GCalEvent>,
>>> > ModuleParserProvider<GCalEvent> {
>>> >
>>> >    public void init(ParserContext context){
>>> >        context.setFactory(GCalParser.class, new GCalEventFactory());
>>> >        context.registerHandler( this, "http://www.w3.org/2005/Atom",
>>> > "category");
>>> >        context.registerHandler( new ColorParser(),
>>> > "http://schemas.google.com/gCal/2005#", "color"); // indicates this is
>>> > for the full namespace.
>>> >    }
>>> >
>>> >    public boolean parseModule(GCalEvent event, Element e){
>>> >        return e.getAttributeValue("scheme") != null &&
>>> >
>>> > e.getAttributeValue("scheme").equals("http://schemas.google.com/g/2005#kind")
>>> >                  && e.getAttributeValue("term") != null &&
>>> >
>>> > e.getAttributeValue("term").equals("http://schemas.google.com/g/2005#event");
>>> >        // returns True, meaning that the GCalEvent module will now be
>>> > associate with the parsed object (entry) and that it should not fall
>>> > through
>>> >        // to any other parsers (here, the default parser for <category>.
>>> >    }
>>> >
>>> >   private static class ColorParser implemements ModuleParser<GCalEvent>{
>>> >       boolean parseModule(GCalEvent module, Element e){
>>> >              module.setColor(e.getText() );
>>> >      }
>>> >   }
>>> > }
>>> >
>>> > Here you can see a few things. First, You can implement a Parser and
>>> > ParserProvider with the same class if you want a parser that works,
>>> > generallly, like the ROME1 parsers. This will make code porting fairly
>>> > easy. Secondly, if you want to avoid the GIANT conditionals we
>>> > currently have, you can provide a separate parser for each element
>>> > name (here the ColorParser). Modules should register their default
>>> > factory providers, but these should be clobberable before parsing by
>>> > dependency injection frameworks, such as:
>>> >
>>> > RomeIO io = new RomeIO();
>>> > io.getParserContext().setFactory(GCalParser.class, new
>>> > MyJPAGCalFactory( myEntityManagerFactory ) );
>>> >
>>> > ModuleParserProviders should be discovered using the standard service
>>> > provider methodology
>>> > (http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service
>>> > Provider) rather than various props files, should be thread safe.
>>> > ModuleParser implementations don't have to be thread safe, unless
>>> > implemented by the same class as the Provider (As above). This means
>>> > that each new instantiation of RomeIO (or similar) should create a new
>>> > ParserContext and init() on the ModuleParserProviders, but the
>>> > providers themselves can be discovered and instantiated once. Again,
>>> > since the registration and parser instantiation steps are separate
>>> > here, that means module authors can either create since instances of
>>> > Parsers inside their provider class if they are thread safe, or
>>> > instantiate new once for each init() call. Since the RomeIO class will
>>> > be thread local on init(), modules could then use it to parse nested
>>> > feeds or reach out to the network for links (in the case of Comments
>>> > in all the GDATA feeds that contain nested Atom feeds). This allows us
>>> > to get around all the places where we are currently addressing the
>>> > feed parser classes directly.
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > :Robert "kebernet" Cooper
>>> > ::kebernet@...
>>> > Alice's cleartext
>>> > Charlie is the attacker
>>> > Bob signs and encrypts
>>> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8
>>> >
>>>
>>>
>>>
>>> --
>>> :Robert "kebernet" Cooper
>>> ::kebernet@...
>>> Alice's cleartext
>>> Charlie is the attacker
>>> Bob signs and encrypts
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> --
> :Robert "kebernet" Cooper
> ::kebernet@...
> Alice's cleartext
> Charlie is the attacker
> Bob signs and encrypts
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nick Lothian]

>
> On Tue, Mar 10, 2009 at 10:44 AM, Robert kebernet Cooper
> <kebernet@...> wrote:
> > I put in a request for https://rome2.dev.java.net/. I will add
> > everyone when the approval comes through. I will start checking in
> > your and my prototype code later this afternoon.
>
> Why not Google Code?
>
> Java.net is double-dog slow these days and even Sun is trying to
> escape from it (see also: Kenai).
>
> - Dave
>
>

+1

Maybe keep the mailing lists and existing website on java.net, but move the code to code.google.com?

Their change tracking & review stuff is rather good.

Nick


IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Robert (kebernet) Cooper]

Google Code it is (that would be my preferred place anyway)

http://code.google.com/p/rome2/

On Tue, Mar 10, 2009 at 3:10 PM, Nick Lothian
<nlothian@...> wrote:

>>
>> On Tue, Mar 10, 2009 at 10:44 AM, Robert kebernet Cooper
>> <kebernet@...> wrote:
>> > I put in a request for https://rome2.dev.java.net/. I will add
>> > everyone when the approval comes through. I will start checking in
>> > your and my prototype code later this afternoon.
>>
>> Why not Google Code?
>>
>> Java.net is double-dog slow these days and even Sun is trying to
>> escape from it (see also: Kenai).
>>
>> - Dave
>>
>>
>
> +1
>
> Maybe keep the mailing lists and existing website on java.net, but move the code to code.google.com?
>
> Their change tracking & review stuff is rather good.
>
> Nick
>
>
> IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
:Robert "kebernet" Cooper
::kebernet@...
Alice's cleartext
Charlie is the attacker
Bob signs and encrypts
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...