camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Krasser <>
Subject Re: [INFO] Project scalaz-camel
Date Mon, 24 Jan 2011 11:08:14 GMT
Hi Claus,

thanks again for your feedback, find my comments below.

Am 23.01.11 11:39, schrieb Claus Ibsen:
> ... Now suppose the core over time could have parts of it replaced with an
> enhanced Scala based core? And we could keep all the existing
> components and whatnot in pure Java language. Then I think we would
> have a great model. Having components in plain Java foster any
> engineer to help contribute to those and its very easy to contribute
> new components ...

Fully agree. That was exactly my initial motiviation behind 
scalaz-camel:  alternative core, reuse components and some parts of the 
existing core such as type converters, for example.

We could also provide a Camel component development kit for Scala 
developers as well. It could perfectly co-exist with a Java-based one 
and contributors have the choice.

> ... However we must ensure that the we dont abuse and make the core code
> to complex and un-understandable for the framework developer.
> We want to let people who want to dig deeper into Camel be able to get
> into the core and be able to become a valuable committer and
> maintainer of the project ...

Having the right concepts and abstractions that are not (yet) widely 
known (and that take some time to understand) doesn't mean that a piece 
of software is complex. It's only something new, It's a bit comparable 
to listening the first time to a foreign language.

I doubt that it's a good idea to sacrifice the right abstractions 
because they could require additional effort and time for framework 
developers to learn them. Instead, let's try to make it as easy as 
possible for them to get into these and make the advantages very clear. 
Maybe there's little chance to loose some contributors but you also 
attract new contributors as well ...

I think we both fully agree that new concepts and abstractions must be 
well documented and explained. I'm convinced that this is doable for 
scalaz-camel even without requiring developers to dig into advanced FP 
concepts ... that's on my todo list.

> Obviously spending some time writing "beginning with" user guides and
> examples would be a solution to let users get started with scalaz.
> That said I agree that "richer" DSL is the future for not only Camel
> but for many domains.


> ... Writing documentation from the very start is IMHO very
> important for the project ...


> In todays internet world, the competitor is just one google search
> away and people tend to
> be impatient and if they can't understand and get started within some
> hours they are likely
> to look for something else.

+1. Having good getting-started guides is a must-have. On the other 
hand, if people make a framework choice based on impatience, then 
they'll likely have problems with any framework.

> I would suggest adding some basic and simple examples, such as the
> "Hello World" example of copying a file from an inbox to an outbox
> directory.
> And then add to that with the filter EIP, and then an Content Based
> Router based on .xml and .txt files. And so forth.

Good idea. Fully support that. Any contributions here are highly welcome.

scalaz-camel is still in an early project stage and it will take further 
effort to make it production-ready, both, from the software as well as 
from the documentation perspective. Your feedback helped me a lot going 
into the right direction.

Martin Krasser


View raw message