camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: FilePolling
Date Fri, 15 Jun 2007 16:51:19 GMT
On 6/15/07, Ole Andreas Hegle <hegle@businesscape.no> wrote:
> Hi There
>
> I have discovered some issues with the file-component, but I need to
> clear up one thing here.
>
> Are there any reason why the ScheduledPollEndpoint use the
> "consumer."-prefix on options which go to the ScheduledPollConsumer?
> (initialDelay, delay and useFixedDelay).
> As far as I can se, no other endpoints/consumers use a
> "consumer."-prefix for sorting-attributes. Shall we keep the
> "consumer."-prefix, or shall we move the attributes from
> ScheduledPollConsumer to ScheduledPollEndpoint? What design guidelines
> do you prefer? (If we keep it in the consumer, we must update the
> user-manual on the web)

The reason I separated them out like that was in case the endpoint or
producer had separate properties. Though as an end user, I guess it
kinda sucks :).

The main issue is you create & validate the endpoint; then later on
you create & validate the consumer; which is why I kinda split them up
a bit (so that at each step we can validate the properties used).

It'd be cleaner for end users if we just had a flat properties thing;
but that'd make the possible validation code a tad more complex
(having to check that any remaining properties on an endpoint
parameter map really are destined for a producer/consumer).

If someone can figure out a neat way to solve that so we can add
properties for the producer, consumer or endpoint in a simple way that
also can validate; am really happy to trash the prefix stuff (it was
just the easiest way to get started :)

-- 
James
-------
http://macstrac.blogspot.com/

Mime
View raw message