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.
+1
... Writing documentation from the very start is IMHO very
important for the project ...
+1
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
blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz
