 |
|
<<O>> Difference Topic
RomeToDos
(14 - 12 Apr 2007 - Main.snoopdave)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| |
<
< |
Rome TO DOs
There are a lot of things still to be done in Rome, both fixes and enhacements. Our current list of To-Dos follows.
Content module for RSS 1.0
In RSS 1.0 some people use the description in RSS1.0 Namespace and some people use the Content module for the content, which is the correct way.
We should add the Content module bean, parser and generator to Rome. We should consider an RDF parser (Jena?) to help us with this.
Create unit tests for all Synd classes
We did some testing but we need a comprehensive and automated testing in place.
Integrate feedback from developers on APIs
As people start using Rome (we hope that will happen) we expect feedback to improve both the API (that's why we are ALPHA for now) and the implementation.
Add OPML and FOAF components
Design and implement beans, parsers, generators and conversors for: regular (flat) OPML, hierarchical OPML, FOAF (Planet format), NetNewsWire.
Provide some persistency support
Most likely this will be an Hibernate mapping.
| >
> | See ROMEProposals page | | | |
|
<<O>> Difference Topic
RomeToDos
(13 - 25 Aug 2004 - Main.tucu)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| | | We should add the Content module bean, parser and generator to Rome. We should consider an RDF parser (Jena?) to help us with this. | |
<
< | How to replace or adding parser, generator and converter classes
We need to create documentation on how developers can do that.
Finish mapping from RSS0.92, RSS0.93, RSS0.94 and RSS2.0 to SyndFeed? Syndication module in converter implementations
Things like update frequency, expiration can be converted to Syndication data. | | | Create unit tests for all Synd classes
We did some testing but we need a comprehensive and automated testing in place. | | | Most likely this will be an Hibernate mapping. | |
<
< | Add copyFrom() method to SyndFeedI? (and all *I) interfaces
This will allow, when using alternate bean implementations, to move data from one implementation to another. A deep copy based on the implementation classes of the bean doing the copyFrom invocation. DONE.
fix the [Rome02Tutorials] for 0.3, do not use an inputstream anymore
add a faq entry to explain why
Define subclass of FeedException? to contain XML parsing error line | | | |
|
<<O>> Difference Topic
RomeToDos
(12 - 12 Aug 2004 - Main.tucu)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| | | fix the [Rome02Tutorials] for 0.3, do not use an inputstream anymore
add a faq entry to explain why | |
<
< | Define subclass of FeedException? to contain XML parsing error line | >
> | Define subclass of FeedException? to contain XML parsing error line | | | |
|
<<O>> Difference Topic
RomeToDos
(11 - 27 Jul 2004 - Main.tucu)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| | | Most likely this will be an Hibernate mapping. | |
<
< | Add copyFrom() method to SyndFeedI? (and all *I) interfaces | >
> | Add copyFrom() method to SyndFeedI? (and all *I) interfaces | | | | |
<
< | This will allow, when using alternate bean implementations, to move data from one implementation to another. A deep copy based on the implementation classes of the bean doing the copyFrom invocation. | >
> | This will allow, when using alternate bean implementations, to move data from one implementation to another. A deep copy based on the implementation classes of the bean doing the copyFrom invocation. DONE. | | | | |
<
< | fix the [Rome02Tutorials] for 0.3, do not use an inputstream anymore
add a faq entry to explain why | >
> | fix the [Rome02Tutorials] for 0.3, do not use an inputstream anymore
add a faq entry to explain why
Define subclass of FeedException? to contain XML parsing error line | | | | |
>
> | |
|
<<O>> Difference Topic
RomeToDos
(10 - 22 Jun 2004 - Main.chanezon)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| | | This will allow, when using alternate bean implementations, to move data from one implementation to another. A deep copy based on the implementation classes of the bean doing the copyFrom invocation. | |
<
< | | >
> | fix the [Rome02Tutorials] for 0.3, do not use an inputstream anymore
add a faq entry to explain why | | | | |
>
> | |
|
<<O>> Difference Topic
RomeToDos
(9 - 18 Jun 2004 - Main.tucu)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| | | This will allow, when using alternate bean implementations, to move data from one implementation to another. A deep copy based on the implementation classes of the bean doing the copyFrom invocation. | |
<
< | Simplify plugin mechanism for parser/generator/converter classes
Current mechanism is complicated and it may not work in server environments where you cannot alter System properties at will. | | | |
|
<<O>> Difference Topic
RomeToDos
(8 - 17 Jun 2004 - Main.tucu)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| | | This will allow, when using alternate bean implementations, to move data from one implementation to another. A deep copy based on the implementation classes of the bean doing the copyFrom invocation. | |
>
> | Simplify plugin mechanism for parser/generator/converter classes
Current mechanism is complicated and it may not work in server environments where you cannot alter System properties at will. | | | |
|
<<O>> Difference Topic
RomeToDos
(7 - 16 Jun 2004 - Main.tucu)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| | | This will allow, when using alternate bean implementations, to move data from one implementation to another. A deep copy based on the implementation classes of the bean doing the copyFrom invocation. | |
<
< | Don't generate javadocs for implementation packages
The synd.imp and io.impl should not have public Javadocs. | | | | |
>
> | |
|
<<O>> Difference Topic
RomeToDos
(6 - 16 Jun 2004 - Main.tucu)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| |
<
< | Rome v0.1 | >
> | Rome TO DOs | | | | |
<
< | Rome is a set of Atom/RSS Java utilities that make it easy to work in Java with most syndication formats. | >
> | There are a lot of things still to be done in Rome, both fixes and enhacements. Our current list of To-Dos follows. | | | | |
<
< | Today it accepts all flavors of RSS (0.90, 0.91, 0.92, 0.93, 0.94, 1.0 and 2.0) and Atom 0.3 feeds. | >
> | | | | | |
<
< | Rome includes a set of parsers and generators for the various flavors of syndication feeds, as well as converters to convert from one format to another. The parsers can give you back Java objects that are either specific for the format you want to work with, or a generic normalized SyndFeed? class that lets you work on with the data without bothering about the incoming or outgoing feed type. | >
> | Content module for RSS 1.0 | | | | |
<
< | Rome v0.1 Release | >
> | In RSS 1.0 some people use the description in RSS1.0 Namespace and some people use the Content module for the content, which is the correct way. | | | | |
<
< | | >
> | We should add the Content module bean, parser and generator to Rome. We should consider an RDF parser (Jena?) to help us with this. | | | | |
<
< |
Don't get scared with all the packages in there. Just stick to the com.sun.syndication.feed.synd,
com.sun.syndication.feed.module and com.sun.syndication.io packages and you'll be fine.
We're sorry that only the non-frames version is available now: the java.net hosting capabilities
impose that today, however you can browse locally the framed javadoc included in the binary
distribution.
| >
> | How to replace or adding parser, generator and converter classes | | | | |
<
< | | >
> | We need to create documentation on how developers can do that. | | | | |
<
< | Why this project? | >
> | Finish mapping from RSS0.92, RSS0.93, RSS0.94 and RSS2.0 to SyndFeed? Syndication module in converter implementations | | | | |
<
< | Various flavors of RSS and Atom syndication formats are reaching a tipping point in terms of adoption this year. | >
> | Things like update frequency, expiration can be converted to Syndication data. | | | | |
<
< | At Sun we started various projects involving these Syndication formats. | >
> | Create unit tests for all Synd classes | | | | |
<
< | However when looking around for java libraries to take care of the parsing and generation of RSS we were not satisfied with what we found. | >
> | We did some testing but we need a comprehensive and automated testing in place. | | | | |
<
< | Project Rome was started out of this frustration. | >
> | Integrate feedback from developers on APIs | | | | |
<
< | Our requirements are to ESCAPE from Syndication Feeds Hell. In order to allow that the library must be:
- E asy to use: given a url, get back a feed object independent of the underlying format, and serialize the feed object to the format I want.
- S imple: RSS initially stood for "Really Simple Syndication", and this simplicity is what made the format successful. Specifications wars have made the current situation much more complicated. The goal of the library is to give that simplicity back to developers: each API we use force on us a mental model of the domain and we are using more and more libraries on each project we implement. This library tries to ease the cognitive load of developers and provides a very simple model for feeds and entries, abstarcting out the details of the various underlying formats.
- C omplete: must handle all versions of RSS and Atom
- A bstract: provides a Java-friendly abstraction layer on top of the various syndication specifications, that maps the commonalities of the various feed formats into a single simple JavaBeans? Data Model.
- P owerful: lets me access all the metadata of the feeds regardless of their format. If I need them, lets me access optional metadata expressed in extensions accepted by various formats (RSS 1.0 modules, other namespaces in Atom).
- E xtensible: It needs to define a simple pluggable architecture to provide support for future extensions of the formats.
| >
> | As people start using Rome (we hope that will happen) we expect feedback to improve both the API (that's why we are ALPHA for now) and the implementation. | | | | |
<
< | We set out to create this library in the same spirit as the JDOM library for XML manipulation in Java, incorporating XOM's Elliotte Rusty Harold's pearls of wisdom about API design and refactoring (see Air Bags and Other Design Principles which links his 6 interviews with Bill Venners). Rome implementation uses JDOM. | >
> | Add OPML and FOAF components | | | | |
<
< | Current Status | >
> | Design and implement beans, parsers, generators and conversors for: regular (flat) OPML, hierarchical OPML, FOAF (Planet format), NetNewsWire?. | | | | |
<
< | The Rome library is currently at version 0.1.
Some projects at Sun are already using it and we made some tests, but we don't have formal Unit Tests for it yet (so good for good XP practices:-).
Also we went through a set of design reviews about the API within the team, but we would like to get external feedback before we settle the APIs for good.
For these 2 reasons, Rome 0.1 is still alpha software. Yes, we said ALPHA. | >
> | Provide some persistency support | | | | |
<
< | Further information | >
> | Most likely this will be an Hibernate mapping. | | | | |
<
< | | >
> | Add copyFrom() method to SyndFeedI? (and all *I) interfaces | | | | |
<
< | Previous Releases | >
> | This will allow, when using alternate bean implementations, to move data from one implementation to another. A deep copy based on the implementation classes of the bean doing the copyFrom invocation. | | | | |
<
< | | >
> | Don't generate javadocs for implementation packages | | | | |
<
< | | >
> | The synd.imp and io.impl should not have public Javadocs. | | | | |
>
> | |
|
<<O>> Difference Topic
RomeToDos
(5 - 16 Jun 2004 - Main.tucu)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| |
<
< | Rome TO DOs | >
> | Rome v0.1 | | | | |
<
< | There are a lot of things still to be done in Rome, both fixes and enhacements. Our current list of To-Dos follows. | >
> | Rome is a set of Atom/RSS Java utilities that make it easy to work in Java with most syndication formats. | | | | |
<
< | | >
> | Today it accepts all flavors of RSS (0.90, 0.91, 0.92, 0.93, 0.94, 1.0 and 2.0) and Atom 0.3 feeds. | | | | |
<
< | Content module for RSS 1.0 | >
> | Rome includes a set of parsers and generators for the various flavors of syndication feeds, as well as converters to convert from one format to another. The parsers can give you back Java objects that are either specific for the format you want to work with, or a generic normalized SyndFeed? class that lets you work on with the data without bothering about the incoming or outgoing feed type. | | | | |
<
< | In RSS 1.0 some people use the description in RSS1.0 Namespace and some people use the Content module for the content, which is the correct way. | >
> | Rome v0.1 Release | | | | |
<
< | We should add the Content module bean, parser and generator to Rome. We should consider an RDF parser (Jena?) to help us with this. | >
> | | | | | |
<
< | How to replace or adding parser, generator and converter classes | >
> |
Don't get scared with all the packages in there. Just stick to the com.sun.syndication.feed.synd,
com.sun.syndication.feed.module and com.sun.syndication.io packages and you'll be fine.
We're sorry that only the non-frames version is available now: the java.net hosting capabilities
impose that today, however you can browse locally the framed javadoc included in the binary
distribution.
| | | | |
<
< | We need to create documentation on how developers can do that. | >
> | | | | | |
<
< | Finish mapping from RSS0.92, RSS0.93, RSS0.94 and RSS2.0 to SyndFeed? Syndication module in converter implementations | >
> | Why this project? | | | | |
<
< | Things like update frequency, expiration can be converted to Syndication data. | >
> | Various flavors of RSS and Atom syndication formats are reaching a tipping point in terms of adoption this year. | | | | |
<
< | Create unit tests for all Synd classes | >
> | At Sun we started various projects involving these Syndication formats. | | | | |
<
< | We did some testing but we need a comprehensive and automated testing in place. | >
> | However when looking around for java libraries to take care of the parsing and generation of RSS we were not satisfied with what we found. | | | | |
<
< | Integrate Samples in the codebase | >
> | Project Rome was started out of this frustration. | | | | |
<
< | Include the rome-samples in the rome distribution and build process. | >
> | Our requirements are to ESCAPE from Syndication Feeds Hell. In order to allow that the library must be:
- E asy to use: given a url, get back a feed object independent of the underlying format, and serialize the feed object to the format I want.
- S imple: RSS initially stood for "Really Simple Syndication", and this simplicity is what made the format successful. Specifications wars have made the current situation much more complicated. The goal of the library is to give that simplicity back to developers: each API we use force on us a mental model of the domain and we are using more and more libraries on each project we implement. This library tries to ease the cognitive load of developers and provides a very simple model for feeds and entries, abstarcting out the details of the various underlying formats.
- C omplete: must handle all versions of RSS and Atom
- A bstract: provides a Java-friendly abstraction layer on top of the various syndication specifications, that maps the commonalities of the various feed formats into a single simple JavaBeans? Data Model.
- P owerful: lets me access all the metadata of the feeds regardless of their format. If I need them, lets me access optional metadata expressed in extensions accepted by various formats (RSS 1.0 modules, other namespaces in Atom).
- E xtensible: It needs to define a simple pluggable architecture to provide support for future extensions of the formats.
| | | | |
<
< | Integrate feedback from developers on APIs | >
> | We set out to create this library in the same spirit as the JDOM library for XML manipulation in Java, incorporating XOM's Elliotte Rusty Harold's pearls of wisdom about API design and refactoring (see Air Bags and Other Design Principles which links his 6 interviews with Bill Venners). Rome implementation uses JDOM. | | | | |
<
< | As people start using Rome (we hope that will happen) we expect feedback to improve both the API (that's why we are ALPHA for now) and the implementation. | >
> | Current Status | | | | |
<
< | Add OPML and FOAF components | >
> | The Rome library is currently at version 0.1.
Some projects at Sun are already using it and we made some tests, but we don't have formal Unit Tests for it yet (so good for good XP practices:-).
Also we went through a set of design reviews about the API within the team, but we would like to get external feedback before we settle the APIs for good.
For these 2 reasons, Rome 0.1 is still alpha software. Yes, we said ALPHA. | | | | |
<
< | Design and implement beans, parsers, generators and conversors for: regular (flat) OPML, hierarchical OPML, FOAF (Planet format), NetNewsWire?. | >
> | Further information | | | | |
<
< | Provide some persistency support
Most likely this will be an Hibernate mapping.
Add copyFrom() method to SyndFeedI? (and all *I) interfaces
This will allow, when using alternate bean implementations, to move data from one implementation to another. A deep copy based on the implementation classes of the bean doing the copyFrom invocation.
Don't generate javadocs for implementation packages
The synd.imp and io.impl should not have public Javadocs.
Remove or hide PlugableClasses? class
This class has no business in Rome public API, it's implementation specific and it should be hidden if not replaced with a config framework or component. | >
> | | | | | |
>
> | Previous Releases | | | | |
>
> | | | | |
|
<<O>> Difference Topic
RomeToDos
(4 - 15 Jun 2004 - Main.tucu)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| |
<
< | Rome TO DOs | >
> | Rome TO DOs | | | There are a lot of things still to be done in Rome, both fixes and enhacements. Our current list of To-Dos follows. | |
>
> | | | | Content module for RSS 1.0
In RSS 1.0 some people use the description in RSS1.0 Namespace and some people use the Content module for the content, which is the correct way. | | | The synd.imp and io.impl should not have public Javadocs. | |
>
> | Remove or hide PlugableClasses? class
This class has no business in Rome public API, it's implementation specific and it should be hidden if not replaced with a config framework or component. | | | |
|
<<O>> Difference Topic
RomeToDos
(3 - 08 Jun 2004 - Main.tucu)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| |
<
< | Rome v0.1 TO DOs | >
> | Rome TO DOs | | | There are a lot of things still to be done in Rome, both fixes and enhacements. Our current list of To-Dos follows. | | | Create unit tests for all Synd classes | |
>
> | We did some testing but we need a comprehensive and automated testing in place. | | | Integrate Samples in the codebase | |
<
< | Rome v0.2 TO DOs
- Integrate feedback from developers on APIs
- Feedlist parsers: regular (flat) OPML, hierarchical OPML, FOAF (Planet format), NetNewsWire?
- Hibernate mapping
| >
> | Include the rome-samples in the rome distribution and build process.
Integrate feedback from developers on APIs
As people start using Rome (we hope that will happen) we expect feedback to improve both the API (that's why we are ALPHA for now) and the implementation.
Add OPML and FOAF components
Design and implement beans, parsers, generators and conversors for: regular (flat) OPML, hierarchical OPML, FOAF (Planet format), NetNewsWire?.
Provide some persistency support
Most likely this will be an Hibernate mapping.
Add copyFrom() method to SyndFeedI? (and all *I) interfaces
This will allow, when using alternate bean implementations, to move data from one implementation to another. A deep copy based on the implementation classes of the bean doing the copyFrom invocation.
Don't generate javadocs for implementation packages
The synd.imp and io.impl should not have public Javadocs.
| | | | |
>
> | |
|
<<O>> Difference Topic
RomeToDos
(2 - 08 Jun 2004 - Main.chanezon)
|
| |
| META TOPICPARENT | name="Rome" |
|---|
| | | We need to create documentation on how developers can do that. | |
<
< | Finish mapping from RSS0.92, RSS0.93, RSS0.94 and RSS2.0 to SyndFeed? Syndication module in converter implementations | >
> | Finish mapping from RSS0.92, RSS0.93, RSS0.94 and RSS2.0 to SyndFeed? Syndication module in converter implementations | | | Things like update frequency, expiration can be converted to Syndication data. | |
>
> | Create unit tests for all Synd classes
Integrate Samples in the codebase
Rome v0.2 TO DOs
- Integrate feedback from developers on APIs
- Feedlist parsers: regular (flat) OPML, hierarchical OPML, FOAF (Planet format), NetNewsWire?
- Hibernate mapping
| | | |
|
<<O>> Difference Topic
RomeToDos
(1 - 08 Jun 2004 - Main.tucu)
|
|
>
> |
| META TOPICPARENT | name="Rome" |
|---|
Rome v0.1 TO DOs
There are a lot of things still to be done in Rome, both fixes and enhacements. Our current list of To-Dos follows.
Content module for RSS 1.0
In RSS 1.0 some people use the description in RSS1.0 Namespace and some people use the Content module for the content, which is the correct way.
We should add the Content module bean, parser and generator to Rome. We should consider an RDF parser (Jena?) to help us with this.
How to replace or adding parser, generator and converter classes
We need to create documentation on how developers can do that.
Finish mapping from RSS0.92, RSS0.93, RSS0.94 and RSS2.0 to SyndFeed Syndication module in converter implementations
Things like update frequency, expiration can be converted to Syndication data.
|
|