Hi Sean, > I am concerned about abandoning the fluent style of > configuration as I found > this a tremendous advantage and selling point of the > architecture. It is a very > good thing to be able to examine one Java file and see the > entire application > layout before you. It is also nice to be able to say there's > no need for XML > other than (in our case) for Tomcat integration. If it were > up to me, I'd ditch > Tomcat too, but it's a culture thing.
I was proposing to do without the fluent builders, not to do without the pure Java configuration. If there is enough interest (pressure) I'll reconsider the fluent builders removal. > I will have to reserve judgement on XML based configuration > and deployment until > I see it, but I can't imagine it being clearer than the > fluent style. We happen > to deploy our services standalone and so deployment is not a > big deal for us. I > don't know the history, but I expect part of the reason we do > this is to avoid > all the XML deployment crap. Absolutely, I don't want to use XML where it doesn't add value. IMO, it only adds value when some configuration has to be edited by some non-Java persons. The plan is to rely on XML only for the Container configuration (the list of server connectors, client connectors and application attachments). Anyway, it will always be possible to achieve the same result using Java classes. I understand this is important in some case, especially embedded and standalone applications. Also, all applications descriptors/configurations will still have to be done in Java only. > Where I work, we choose Java and POJOs over XML and > enterprise beans. This is > one reason Restlet is so appealing to us. In the short time > being involved with > Restlets, I sense a trend to back away from the purity of the > model. I'm no > purist or RESTafarian by any stretch; I'm more interested in > getting work done > in the real world. But I wonder where the line is. This > concern could be just be > my imagination... No worry, I share the same concerns. You will still be able to do everything using Java and POJOs only. XML is just an option when the container has to be separately managed from the applications hosted, for example by an admin who doesn't know Java or don't want to recompile each time a new application is deployed in the same container, sharing the same HTTP connectors for example (virtual hosting). > I am glad to hear there is a sensitivity to API changes > because that's very > important to me, Restlets are gaining a user base here and so > stability is > important. There's at least one bug in b19 I really need so > I'm gonna have to > figure out a migration strategy. I'm still trying to follow this roadmap at http://www.restlet.org/roadmap However, beta 19 won't include all the planned features as it's already too large and needs to be released. So we'll also have a large beta 20. After that I'm really hoping to go on the RC (Release Condidate) cycle, which means API is frozen, except to fix bugs. Also, looking at the features remaining for beta 20, I don't expect API breaking changes in org.restlet, probably in com.noelios.restlet (JDBC refactoring). Thanks, Jerome
