On Wed, Aug 31, 2011 at 3:28 PM, Christian Schneider <ch...@die-schneider.net> wrote: > Currently the file component uses a special message GenericFile to send > files into camel routes. > This is bad as several other parts of camel need to deal with this type. It > is already a bit better now that I introduced WrappedFile as an abstraction > of GenericFile so other parts of camel do not have to know details about the > file component. >
This is not bad as its an abstract the component offered. So if you use file/ftp/xxx you would have that GenericFile at your disposal. Now the Camel type converters would make it easy to get a java.io.File (if its a file component), a InputStream (which is what the ftp components offers), or some X other object that contains access to the underlying file implementation. Frankly by introducing WrappedFile in the root package, which is, according to you, a temporary solution, is a bad idea. You now add more confusion to the mix. Just because a structure 101 diagram should have one less arrow less. Instead you end up pushing more and more to the root package, and make it more and more general. Abstract over abstraction :( > The big question is though can we get rid of this completely? > > So my proposal is: > > - Send files as File objects in the body of a regular DefaultMessage. We > could also think about sending a FileInputStream > - Send other details as headers > - Also get rid of FileBinding > > So what are your thoughts about that? > Camel 2.x should be kept backwards compatible and API stable. We have end users who build custom components on top of the Camel file component and rely on the API being as is. The camel-ftp component is built on top of the file component and the generics help making this possible. Back in the days when the file component was created for camel 2.0, it was meant to be a building block for file based components such as - ftp - commons-vfs - a webdav component It still makes sense to have it as a base component for file based components. Today commons-vfs is a dead project. But we frankly still miss a webdav component. For Camel 3.0 we may consider adjusting pieces of it, if it makes sense. So to re-iterate my thoughts. Keep the 2.x as is. Consider changes for Camel 3.0 if it makes sense and is feasible. > Christian > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
