search

rometools / rome

Java library for RSS and Atom feeds
https://rometools.github.io/rome
Apache License 2.0
911 stars 168 forks source link

Rome 2 Questionnaire #353

Closed mishako closed 7 years ago

mishako commented 7 years ago

Hi everyone!

If you're interested in the future of Rome, please fill out (and share) this google from. If you don't have a google account, or don't like forms, feel free to write your thoughts in the comment section below.

The text below is a copy-paste from the form.

I would like to initiate development of Rome 2.

With recent announcements of JSON Feed and new Itunes RSS tags Rome starts lagging behind. While some modifications are relatively easy to implement, other are not at all. On top of that the Rome codebase is ancient and does not particularly boost productivity.

This is why I would like to suggest a complete rewrite. There is nothing advanced in what the current code does. I believe it can be easily replicated, improved and extended.

Here is a random list of things I would like to see in the new version:

  • Java 8
  • Better API (something like Rome.minimal().readUrl("..."), see more in this gist)
  • Android support (as in we know it works, not just assume)
  • Drop support for old standards (e.g. RSS 1.0)
  • Get rid of rome.properties
  • Expose raw strings for fields like date (in addition to the parsed value)
  • Similarly expose parsing errors (also never fail completely because of invalid fields)
  • Expose the old SyndFeed object (to ease transition)
  • Single artifact (merge core rome and rome-modules)
  • Single maven dependency: slf4j-api
  • Code generation (stop writing getters and setters by hand)
  • Immutability and builders

If you agree, disagree or have other ideas or concerns, please fill out the form or leave a comment.

@PatrickGotthard and @imk already questioned some of my ideas. To reach an agreement I'm going to hold a public discussion (in form of github issues) on each controversial topic.

Tagging everyone who has been active in Rome development: @snoopdave @icyerasor @Athou @buckett @IgnacioDomingo @mityi @Joerg-Schoemer @farrukhnajmi @michael-simons @dipacs @markhobson @fschiettecatte @eknoes @mDandini @rchakra3 @puntogil @matwood @sagen @AymanDF @freemarmoset @arankin @janih @tacoo

And reporters of recent issues: @jimsteel @GabrielBB @herau @buko @djvergel @johnedo1234 @dotquam @joaoBeno @Huangbin1234 @adelinolobao @bdurepo1 @endorphins @maxfieb @jannesep

joaoBeno commented 7 years ago

Replied, as you said, Rome is the best lib to parse feeds. There are others, but none as easy and as complete, and an redo in following a modern approach would sure help more people that today are resorting to manually parsing the XML, as I did before.

buko commented 7 years ago

Java8++. The most important thing is that the api should be completely asynchronous. No reason when working with remote services to block anywhere.

Better API is dubious. Quite often I've struggled with projects that attempt to hide all complexity between an simple fluent API. If people do want such a simple fluent API suggest it be built on top of a core API that still reveals full power.

Code generation is a smell. Would definitely avoid it. Writing getters and setters isn't the end of the world.

Builders are IMO an antipattern. I would recommend (1) immutable interfaces and (2) factories that can be configured.

One thing to keep in mind is that today many ppl use DI. This means it's much easier to inject a factory and use that than to prototype builders. Extensions for examples can just be factories.

imk commented 7 years ago

@mishako Thank you for your effort!

@buko I don't think it's bad to hide complexity from your users - as long as you're giving the chance to et full control (and complexity) when needed.

michael-simons commented 7 years ago

I know that @ewolff has been promoting Rome a lot recently as means of communicating between micro services.

mishako commented 7 years ago

So far I've got response from 8 people in total. Not a lot, but great feedback from each of you! It's been less than a week, so I'm still waiting for more responses. In the meantime I started preparing discussions on all the topics: https://github.com/rometools/rome2/issues/1 (subscribe to the issue for updates).

matwood commented 7 years ago

Java 8 +1.

I'm not a fan of code generation.

I would be careful dropping support for older formats. You may lose users and possible contributors.

Rome and its Spring integration has made it super easy to generate an OPDS (Atom+xml) feed. Thanks!

puntogil commented 7 years ago

Java 9 at least 8. About Lombok for me is a couple of wrong intents. Our java packaging guideline (Fedora/Red Hat) do not permit to import pre built libraries. we use only system libraries. And i'm not a fan of these code generators. Maybe you could add a sub module for this kind of need without interrupting the compilation of the main module due to these waves Regards

fschiettecatte commented 7 years ago

I'll pitch in with suggestions:

I have no real opinion on the other items, I will leave it to better qualified people than I to decide.

imk commented 7 years ago

@puntogil could you explain your packaging guidelines a little bit more detailed? What does the restriction to system libraries mean, you're restricted to using packages allready in your rpm repository? Or you aren't allowed to use any dependency for compilation? Rome allready has dependencies, required for compilation and in runtime. These are approved system libs for you? So the challenge would just be getting all dependencies approved as system libs?

puntogil commented 7 years ago

@imk see https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries

imk commented 7 years ago

@puntogil thanks for the link. There's an paragraph about Use of pregenerated code, that imho allows the use of code generators. Lombok (or other code generators) seems to be compliant to this guide (at least in my understandings of the guideline, maybe I'm getting something wrong).

puntogil commented 7 years ago

@imk For Fedora the problem is lombok (we use the last release for each library we imported and for us it is not feasible, as for aspectj and others ....)

michael-simons commented 7 years ago

Lombok isn't needed in the final distribution. Only during build IMHO.

puntogil commented 7 years ago

@michael-simons This was already quite clear without having to repeat it

puntogil commented 7 years ago

Maybe it escapes us that we do not use sw pre built

michael-simons commented 7 years ago

@puntogil I just wanted to contribute, didn't read your guidelines. No need to be angry.

Besides what doesn't seem to be clear that Lombok doesn't generate source code but modifies the AST directly during compile time.

michael-simons commented 7 years ago

@frvabe what was the reason to remove Lombok in Camunda again?

puntogil commented 7 years ago

@michael-simons I'm sorry I did not want to give this feeling, I wanted to be clear about lombok only

michael-simons commented 7 years ago

Thanks, @puntogil Everything fine. I have scrolled over the Red Hat / Fedora Guidelines, pretty good read (apart from the discussion here).

Apart from Lombok, things I like to fix, have fixed or changed are things like those: https://github.com/michael-simons/rome/blob/4fc566547ec17ef79f5003c777b3936e19af43cd/rome-modules/src/main/java/com/rometools/modules/atom/modules/AtomLinkModuleImpl.java#L32-L57

Passing mutable state around. IMHO more important to fix that. Can be through builders or through modifiers like in Java 8 Date/Time-API.

imk commented 7 years ago

@puntogil @michael-simons Thanks for your feedback, I think the details of the different code generation tools isn't the main point here, to me the conclusion is that there are some projects or use cases where code generation may be an obstacle and the subject is more controversial than expected.

michael-simons commented 7 years ago

@imk Yes, that's my impression, too. As it isn't too hard to generate accessors, its not the most convening use case. Constructors might be. But TBH I think that it's better to keep it out.

imk commented 7 years ago

@michael-simons yes, Immutability is on the list and not too controversial :o) (of course there are some questions how to implement it best and come up with a convenient way for the user to change data on a feed while the feed itself is immutable etc.)

FrVaBe commented 7 years ago

@michael-simons Have a look at #152 for the reasons why lombock was removed in the camunda-spring-boot-starter project.

imk commented 7 years ago

@FrVaBe thank you for the link, the decision seems mostly been taken by personal preferences (or aversion) than by real problems with code generators in general (and especially lombok). Personally, I don't get why there's so much aversion but if it's an obstacle in getting people involved, we have to consider that.

FrVaBe commented 7 years ago

@imk It causes some kind of trouble to get it work in eclipse IDE even for an experienced developer. Of course you can blame it on eclipse but it is better to avoid this kind of trouble - especially if it is of less value for the project. But as always it depends...

I agreed to @berndruecker s comment that the usage "is not a good idea for a community extensions, which lives from being easy to checkout, build and understand!" - but as I said I don't know if this is the case for this project too.

ewolff commented 7 years ago

FWIW: You can find the microservices demo @michael-simons is referring to at https://github.com/ewolff/microservice-atom .

mishako commented 7 years ago

Thanks everyone for your input! It was very useful for making the initial decisions: https://github.com/rometools/rome2/issues?q=is%3Aissue+is%3Aclosed

I will close this issue now. Follow rome2 repository if you want to stay in the loop. The next step for us is to start building a throwaway prototype. Feel free to raise questions or concerns: either by creating a new issue, or by commenting in any of the open or closed issues.