Great ideas, thanks for the input. What about using the "different roles" of an entity to model either the different places it can be (and so having different view on the same message) i.e. draft, outbox, inbox, trash. So you just add a interface and mixin and use Entity.cast to supply it with the different states the views require.
The same seems to be possible with the topic. Just add another Composite interface for the properties related to topic and then use that as required. Perhaps topic is only one of many message attributes that we have to look at (see the QoS, Security & co aspects that also could be done with Concerns or SideEffects). If you look at emails in your email system. These are really instances of an email type which is created at the sender, stored in draft then outbox and sent if some condition holds true (server available, time to send, manual sending). Then the message keeps living in the outbox and a separate view (or entity state copy) of it is serialized and transferred over the wire over lots of stations which use other concerns to evaluate (spam) route and finally deliver the email entity to the recipients system. There the last service (entity store) makes it available for the client which queries the entity store (using imap or pop3) for new messages every x minutes polling (or is pushed the messages actively by a service - blueberry). Then at the receivers client there is a local entity store (inbox) which holds the messages and can be queried (keyword filtering etc, attribute sorting & filtering etc.) by the user. Sound perfectly fitting. With business busses you add more QoS, Reliability and Transactions, Security to the picture. But in general it keeps the same. Regarding multicast; publish/subscribe etc. these are just concerns that can be added to the message as needed. Perhaps looking at Gregor Hohpe's Enterprise Integration Patterns would help to identify the most important properties we have to support? Michael Niclas Hedhman schrieb: > On Tue, Aug 12, 2008 at 3:07 PM, Rickard Öberg <[EMAIL PROTECTED]> wrote: > >> Well, I was looking at my Thunderbird email, and the way to deal with >> this is to either have different "Outboxes"/"Draft folders" which are >> connected to specific Accounts, or the To: is set to the "topic" (e.g. >> this mailing list). Different granularity, but in effect, an Outbox >> would be a separate Entity, not stored in the "messaging EntityStore", >> but rather in a normal store and yet referenced from the Message, and >> then the message sender simply follows the reference from the Message to >> find out where to send it. Or, if there is a generic "To:" header, use >> that, and let the Account settings decide what transport to use (SMTP, >> XMPP, JMS, etc.). > > I think that the above is talking about the "Association" trick into > 'global' entities acting as orthogonal identifiers (think 'labels' in > GMail). > > If so, yeah, maybe "good enough". I am sure we will get more insight > down the road. > > >> On the consumer side, another crazy idea is to use blocking >> EntityFinder's. Basically, a consumer would make a Query which is then >> sent to a Finder. > > Right. Although I would like to see support for being called on a > method instead. I.e. client is ultra-dumb and only act when called, > and doesn't even need to know that messaging is involved. I guess that > functionality will end up in a library. > > But there is more to it than that. > > a. Cardinality of consumers. > b. Life time of messages. (Possibly outside handler). > c. Various QoS aspects. > d. Security (mentioned before). > > >> If a message comes in and there is no consumer that is asking for >> hasNext() in a Query, the EntityFinder/Inbox can choose to either throw >> away the message (if it is a transient one), or store it until a >> consumer becomes available. Both cases are useful. > > Right. Same goes for QoS aspects like Latency, NoNuplicates, > NoneMissing, InSequence and so on. > > I think our immediate problem relates to experience. If anyone reading > this list have experience beyond basics of ActiveMQ/JMS and similar > system, please speak up. > > > All-in-all, I think we are on Da Way. > > > Cheers > Niclas > > _______________________________________________ > 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
