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
