On 6/15/07, Ole Andreas Hegle <[EMAIL PROTECTED]> 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/
