Niclas Hedhman wrote: > I disagree completely!!! > These are not crazy, but very good ideas! ;o)
:-) > Topic seems to be a feature we need to figure out. I think (but not > sure) that the Topic is needed to be calculated in runtime, and not > statically set at development. 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.). With this in place we can easily make GUI's similar to email clients where we can monitor and drag/drop messages between different Outboxes, and on the other side, Inboxes. > I can see two ways on how to implement Topics; > > 1. Require a "MessageEntity" type, which has a Topic property. = To: "property". > 2. Add the Message instance to a Topic "Association tree", and the > EntityStore deals with that. = Separate Outbox Entity. > In general, I think you are on to something pretty neat, and the > 'sending side' is probably pretty straight forward. I think we need to > look at the consumer before deciding. Right, so this is what I was hoping for. "So far so good", but as pointed out, neither of us are messaging experts so there must be something we've missed (or can it be this simple??). 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. Either the Finder returns with the results immediately, or, it could return an Iterable which provides the messages that are immediately available, but when the Inbox becomes empty it simply blocks on "Iterator.hasNext()" for a configured time (e.g. 5 secs). If something comes in during that period, that is returned from hasNext(), and if not, then hasNext() returns false, and the consumer can decide whether to stop, or to do another round of hasNext() calls. All the error handling would be in the EntityFinder implementation, so that consumer only has to deal with hasNext() returning true or false. Again, the assumption is that we want to make application code as simple and error-free as possible, and deal with all the nitty gritty in SPI-extensions, such as the message sending EntityStore and the message consuming EntityFinder. 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. If we do it this way I can imagine that we can have a system similarly to sending a Message associated with Outboxes, i.e. an incoming message gets associated with an Inbox Entity, so that the query from the consumer becomes "give me all Message Entities which has the association Inbox set to 'myinbox'". /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
