Hi Guillaume,
I am not absolutely mandating a rewrite. The new API will simply allow
us to do any change in core we want. That can be a rewrite but it does
not have to be.
I know that the aproach with a new API is more work than a simple
refacturing. The big advantage is that we can stay compatible with the
old core using the bridging.
So we will have some time to convert the modules and also refine the
api. Hadrian brought up the great idea that we can in fact create the
new API and the bridge before we have to
really start a camel 3 branch.
My proposal does not even touch the DSL though. The API should in a
first step only be the foundation for component developers.
A next step is the Model and the DSL. I have not done enough experiments
with this to have an opinion how a new model and DSL should look like.
It is unlikely though that any bigger change there can stay compatible.
I think DSL and model should be separated. Basically we even now have a
separation between dsl and "model". The dsl elements already create the
processors to run the routes. The main change I would like to see here
is that runtime model does not use processors but a richer abstraction
of the model. What I would like to achieve is that the runtime model the
dsl creates does not contains any cross cutting concerns like
transaction, security, ....
A nicer DSL would be great but we could even delay that till camel 4.
I can not prove though that this aproach is necessary. I would be really
glad if someone manages to refactor camel to a clean API without this
big step. So the first thing we have to do is decide if a new (kind of
independent API)
is really necessary. The best way to achieve this is to try to refactor
core in a branch or a private checkout and see how far you get. I would
like to encourage everyone to try that and report their experiences. So
if a refactoring is possible I am glad to abandon the idea with the new API.
Christian
Am 27.02.2013 10:32, schrieb Guillaume Nodet:
cschneider, what you basically suggest is to rewrite camel, and create a
layer to bridge the old to the new camel.
Before going this way, I'd like to understand why is that necessary (but
the fact that it's cleaner, which in itself is nice, but not sufficient to
me).
I do agree that the model and main dsl is mixed together, though this does
not prevent writing other DSLs or inventing a new one for java in a
different module. In addition, it's more a fluent api than a dsl, so if
you want to remove this api, you still need a way to create the camel model
with routes, processors, endpoints and all. So imho, trying to remove the
java dsl from the model will just lead to 2 different things, one with a
nice api but ugly to manipulate and another one which defines wrappers
around the model with a nicer api. I'm not really sure what the real gain
would be, it may even lead to a more heavyweight camel at the end.
For the xml dsl, one thing to remember is that it's just a few annotations
on the existing model, so removing it will mean having a duplicate object
model generated from an xsd and a translation : it's not more lightweight
either. Also if we end up with different intermediate model for the xml,
it needs to be kept in sync both ways, as xml is the usual serialization
format for the model.
It's even totally doable to write a new xml dsl for 2.x if needed because
the existing one is found too limitating. I'm sure it's also possible to
write another java dsl on top of 2.x too.
So at the end, I'm not buying the DSL argument at all.
I don't think a 5 man-year effort should be started for no purposes than
just cleaning things. I think it will end up as Karaf 3 which has now been
started 2 years ago and not released yet. So I'd like to understand why
such a big change is *necessary*.
The problem in rewriting a new api is that it will take a very long time
for users and for other projects to switch. If they don't see the need for
switching, it will delay even more.
In addition, and that's what has happened for Karaf, if the developper
community is not convinced that the new major version is needed, you'll
reduce the workload to work on the 3.x branch and it will be even worse.
So while having a thiner camel-core would be nice, and having a cleaner api
would be nice too, I certainly don't want to go there at all costs. The
work that has been done with the introduction of the ModelCamelContext to
break the dependency between the api and the model is really good, and I
really think we should go in that direction. If we further add a
ModelRouteContext, I think that would definitely split the api from the
model.
More generally, I think we should really go this way: i.e. refactor the api
step by step on 2.x / trunk to clean things, eventually split if possible
and when the 2.x contains both the deprecated api + the new one, create a
3.x branch and remove the deprecated apis. This would ensure
#1 no pause in development and bringing new stuff to users by working on
a single branch
#2 that 2.x is fully compatible with 3.x
#3 that users have ample time to get rid of the use of deprecated apis
On Wed, Feb 20, 2013 at 8:32 AM, Christian Schneider <
ch...@die-schneider.net> wrote:
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
