Refactoring or new api. Is that really the goal in itself ? What new features are needed that can't be done with the current code ?
Anyway, there's no real point in discussing that really. if you want to experiment with a new api, just do it in a branch and we'll discuss that once there is something to see. You don't have to ask for permission to do it, though you need to inform the community about it. Which is done now. That's exactly what I told Hadrian at ApacheCon. Do it in branch or sandbox. Then, discuss it. On Wed, Feb 27, 2013 at 12:43 PM, Christian Schneider < [email protected]> wrote: > 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 < >> [email protected]> wrote: >> >> > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
