On Wed, Feb 18, 2009 at 6:12 PM, William Tam <email.w...@gmail.com> wrote:
> On Wed, Feb 18, 2009 at 7:53 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
>> On Tue, Feb 17, 2009 at 4:57 PM, William Tam <email.w...@gmail.com> wrote:
>>> I agreed with the convention. Just one question, are we going to have
>>> component neutral headers that can be understood by more than one
>>> component? If we are, what's the convention and where should they go
>>> in the source? The obvious reason is the "interoperability" between
>>> components. For example, if I am writing a component that needs to
>>> understand http headers. my component will then have to check for
>>> CamelHttpResponseCode and CamelRestletResponseCode to be able to work
>>> with Http and Restlet components.
>> I think each component should keep the headers in its own "namespace".
>> So yeah you component should check for both.
>> In fact it can probably just check for endsWith("ResponseCode") to
>> cater for different prefixes.
>
> Checking for endsWith("ResponseCode") is not always safe. I can have
> a header that ends with a same substring but it can have totally
> different semantics.
>
> The issue that I see is that it is promoting components to hardcode to
> only work with a set of components. It implies:
>
> * A component that receives headers has to check for the ALL
> Camel{XXX}ResponseCode. It hardcodes all the senders.
>
> * A new component won't to able to send header to an existing
> component (for it to understand header), unless the new component
> sends the "right" headers. Basically, the sender needs to create
> headers Camel{XXX}ResponseCode for ALL the components can read the
> headers. It hardcodes all the receivers.
>
> Suppose the header we are talking about has well known semantics. If
> the user started with a working route from(a).to(b) and then change it
> to from(c).to(b), component "b" may or may not be able to interpret
> the header from c, but it ought to work. So, it impacts users as well
> not only just the developers.
>
> Just to throw an idea out. What do you think of a header is more than
> a string? If it is an object, it can be embedded with more
> information. Things like actual name to be used in protocol,
> component name, well known semantics (e.g. whether the header is a
> response code, username, password, etc).
Yeah I think you opening a door for something bigger here. To keep it
simple I would like to get the current problem with the KEYS fixed
first.
Then we can tackle your great idea of having a container object for
the value. If the end user wants the plain value we can use type
converters
so he wont have to go throught this container object first.
And in line with my latest proposal to add constants to Exchange for
well known keys we could actually maybe reuse common key name,
so we have a single RESPONSE_CODE, CONTENT_TYPE, USERNAME, PASSWORD.
But lets get the first issue done, then we can focus on the next step
afterwards. BTW: Maybe your ExchangeProperty could be handy here?
>
>>
>>
>>
>>>
>>> On Tue, Feb 17, 2009 at 2:58 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
>>>> Hi
>>>>
>>>> We have a bullet on the Camel 2.0 design page:
>>>> http://camel.apache.org/camel-20-design.html
>>>>
>>>> Bullet:
>>>> using Camel${component}${name} pattern as header keys instead of using
>>>> package names with dots that isn't likely to be transported by JMS or
>>>> other transport types
>>>>
>>>> Currently we have mixed content using the old style (using package
>>>> names) and the new style.
>>>> What I would like to get done before we have a M1 version is to get
>>>> this fixed beforehand.
>>>>
>>>> As the change involves looking into all components and fixing it one
>>>> by one it would take some time.
>>>>
>>>> If you are in doubt why we should do it, then i will quote what
>>>> Jonathan wrote on IRC
>>>>
>>>> "this is CamelCase style"
>>>>
>>>> Well spotted Jon, of course we should have CamelCase in Camel :)
>>>>
>>>>
>>>> Any thoughts?
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
