Niclas Hedhman wrote:
> On Thu, Aug 21, 2008 at 11:39 AM, Rickard Öberg <[EMAIL PROTECTED]> wrote:
>
>> On the one hand it would be nice to not have to do all the transports
>> that they've integrated, but on the other hand so far it is relly
>> frustrating to get it to work, and it brings in the entire Spring and
>> JAXB dependencies really fast.
>
> Yes... Wasn't there a similar out-of-body experience with Apache
> Abdera recently??
Indeed.
>> public interface MessageComposite
>> extends EntityComposite
>> {
>> Property<String> messageId();
>> Property<Map<String, Object>> headers();
>> Property<Map<String, DataHandler>> attachments();
>> Property<Object> body();
>> }
>
> Headers Ok, I might live with that.
>
> Attachments and Body --> Body is just another attachment, that in
> reality just preceeds Attachments in the evolution and has become like
> a "default" attachment.
>
> And I thought we should place attachements as Property instances in
> MessageComposite subtypes that the user can do whatever he likes with,
> type-safe and all. Perhaps you have a plan for keeping the
> attachments, headers and body as is, and some clever Concern will
> delegate up to the suggested methods?
Nope, no clever plan. It's as usual: do something really stupid that we
can say "no that's bad, do it this way instead".
Another way to do it, by the way, is to have AttachmentComposite as an
Entity instead, which will allow users to view Messages without bringing
in all the Attachments. Then we could also have subtypes of that for
specific attachment types, such as URLAttachment, FileAttachment, etc.
>> So I'm not sure how to proceed really. Any thoughts?
>
> I am not experienced with Camel, but my guess is that it is similar
> enough to Mule in this respect; Shitload of dependencies and a
> straight-jacket in the set-up. As most of the cases, I think recommend
> a "Fork the useful bits" again, meaning if it is the Transports we
> want, then we fork those. Also, we should provide a simple solution to
> bind our In/Out boxes with "JVM"/"InMemory" end points of Camel and
> Mule. I bet the footprint will be a fraction of the size... I hate to
> end up in the NIH-camp, but most OO solutions and subsystems are just
> too "fat" to be re-used effectively.
Yeah, I'm not too happy about the NIH-thing either, but so far it..
just.. sucks.. too.. much.. aaargh.... can't anyone ever get this stuff
right. *sigh*
I think I'll skip Camel for now and just focus on getting the model
correct with Inboxes, Outboxes, Attachments and so on, and we can look
at actual messaging transports after that.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
