On 2010-11-06 14.07, Niclas Hedhman wrote:
It looks pretty good. But one thing that 'bothers' me is the static
class methods for Inputs and Outputs. They are not very extensible
without having access to the library itself. I assume that we don't
want that in Qi4j at all and instead have some type of
injection/lookup/resolution...
The static methods are just for easy collection and access of standard
inputs/outputs. They could just as easily have been made as regular
classes. I.e. instead of:
Inputs.text(source).transferTo(Outputs.text(destination));
you would do:
new TextInput(source).transferTo(new TextOutput(destination));
You are right that the statics make them less extensible, but they also
make them easier to use (IMO). Both variants are possible though.
Use-case to consider;
Qi4j don't ship PS/PDF support. I want to extend Inputs to handle some
Postscript format and Outputs to handle some PDF format and a mapper
in between.
I'm not sure that's the best example, since for reading files like that
you will end up with one object (a PDF-document) rather than 1-line->1
PDF-object. But for any such transformation, like the String2JSON
example, you just create your own Function<From,To>.
Another thing I raised my eye brows for;
Input<String,IOException> input = ...;
Output<JSONObject,RuntimeException> output = ...;
input.transferTo(Transforms.map(new String2JSON(), output);
shouldn't it be
input.transformWith( new String2JSON() ).transferTo( output ):
On an Input the ONLY thing you can do is .transferTo(Output). So the
only way to get in transforms in the middle is to decorate the output,
map() does for you given a Function.
And it also feels just a stone throw away from stuff like Camel!!
Yes, there's lots of integration thingies that becomes quite easy with
this as a foundation.
One things that comes to mind; How about async transfer? Maybe there
is no need to block the thread for the transfer, and if the slow
endpoints are NIO based, then no need to use up a lot of threads for
this.
There is an assumption that the transfer is done synchronously. When
Sender.sendTo() returns the Receiver is allowed to clean up its
resources that it was writing to, so if the Sender calls receive(item)
later on, asynchronously, that screws things up. It would probably be
better to create a separate API for that usecase, since it is quite
different.
All in all, the simple APIs looks good (perhaps with some async
semantics as well). If we can come up with a way for the
implementations to reside outside Qi4j Core, then we have something
very powerful.
My plan is to have the basics within Qi4j (e.g. read lines from a text
file), and then have Inputs/Outputs where it makes sense (EntityStores
especially). Outside of that developers are free to create their own
Inputs/Outputs/Specification/Functions to shuffle data any way they see fit.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
