camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Discuss] Remove generics and special message from file component
Date Thu, 01 Sep 2011 06:09:22 GMT
Hi Claus,

I first did not see the connection to camel-ftp. I now see that it is 
necessary at the moment. I think there are simpler solutions though.
I will work out a proposal. Of coure this is not for camel 2.x. The 
change would be too big.

Christian


Am 31.08.2011 21:34, schrieb Claus Ibsen:
> On Wed, Aug 31, 2011 at 3:28 PM, Christian Schneider
> <chris@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
>>
>>
>
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message