> 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. + 1 on that - so you may also have an EncryptedAttachment or an Attachment that wraps another (like multipart attachment). > >>> 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
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
