+972 52-548-6969
LumenQ: API
time to read 2 min | 248 words
I am posting this because I really have no choice, I don’t want to build another product right now, but the design is literally killing me, bouncing in my head all the time.
The following is the low level API that you would use with LumenQ, a Silverlight queuing framework.
var postOFfice = new PostOFfice("http://my-server/lunemq/messages") .RegisterForTopic("/customers/939192") .RegisterForTopic("/notifications") .OnMessageArrived(HandleMessageFromServer) .Start(); postOFfice.Send(new MyRecommendations { UserId = 9393 });
Note that OnMessageArrived is a low level API, there is also an API similar to the Rhino Service Bus, which allows you to inherit from ConsumerOf<T> and gain strongly typed access to what is going on there.
Messages to this client will include:
- Any message on the /customers/939192 and /notifications topics
- Any message posted specifically to this client
I am still struggling to decide what sort of infrastructure support I want to give the library, things like error handling are drastically different than in the Rhino Service Bus world, for example.
Comments
Nice API (FWIW, I actually prefer this API to what I've seen of Rhino Service Bus). Do you actually have a need for such a product, or would you be doing it mostly as an academic exercise?
Troy,
I am considering making this a commercial component.
OH HAI. I CAN HAS JAVASCRIPT SUPPORT? WIF NO DEPENDENCY ON SILVERLIGHT. AN FREE. K THX
Free, probably not.
JS support, give me a scenario.
And please drop the LOL cat syndrome,
Sorry about that. I don't think I have a javascript scenario complicated to justify you needing to work on it. I'm sure what you do for Silverlight would be great. A javascript only implementation probably would not be as interesting to you since there is no sizeable client-side cache to work with. I'd think the useful scenarios would parallel the same scenarios as your recent MSDN smart client RSB.
I'd like to +1 Steve - we're building something similar (for a project, not as a product) and System.Reactive has proven to be incredibly useful. Your api becomes very clean and expressive, unit testing becomes a breeze, and you hardly even have to think about the fact that it's multithreaded...
It really comes into it's own when you have to do things like joining or zipping observables.
Plus there's RX for javascript, so maybe that javascript client that fschweit was after (and there's plenty of client side databases (html 5, google gears) that could cache).
Cheers - Rob
P.S. i LOVE the fact that you're posting this immediately after saying "i'm just too busy with this programming stuff, i think i'll go watch tv". How many minutes of blobbing in front the the telly did it take before you'd architected lumenq?
What are these queuing frameworks used for in particular. Real world example?
Cheers,
Adam
Uhhh that PostOffice name makes me shudder^^ What about MessageQueue, MessageService, MessageDispatcher or MessageBus? If you want some branding you could prepend Lumen to the identifier.
Steve,
void HandleMessageFromServer(Message msg)
{
}
class Message { Topic, MessageValue, SendAt }
I'll look at System.Reactive, sure.
Rob,
That is the magic of future posts, this particular post was written 3 days before it was published
Adam,
For example: msdn.microsoft.com/en-us/magazine/ff872394.aspx
@Rob
The reason for going with a Javascript only client is to support any web visitor without extra installs. For that reason if a persistent client-side store was used, I would use something Flash-based, before Silverlight, and well before things like Google Gears (based on install base). Such a constraint is not useful for very rich client apps, but it can make sense when revenue comes from ad impressions.
I do not yet see why Reactive Extensions is a better model for handling events or messages. I'd be interested to hear Ayende's opinion on how it could complement or replace other messaging infrastructure. The last I heard he hasn't looked at it.
Comment preview