3 ms·

I'm not sure what main application you're referring to. Every diesel node is an instance of an application that is willing to be provide a service that acts as

by jamwt 17y ago

I'm not sure what main application you're referring to. Every diesel node is an instance of an application that is willing to be provide a service that acts as the master/router for a certain class of messages. Paxos ensures there is only one master elected for every message class, and this router is re-elected should the router go down. The routing table of who is master for what class of messages is kept in sync across all nodes. It's almost exactly like registered processes in an erlang cluster--reserving the exclusive right to handle certain messages. Simpler master/slave relationships can take over from there.

jamwt 17y ago
So, maybe we agree? Because I'm not disputing (and never have) that the message broker is the place to do that. But you seem to be conceptualizing the message broker as a separate _service_ or application, and I'm saying it's just a function, a role. It doesn't matter so much what particular process (or group of processes) it runs in. That's what I meant by "internalize".
moe 17y ago
Every diesel node is an instance of an application You mean one that the user writes (starting with "import diesel")? If so then I'd think such a tight coupling is a bad idea. Why prevent non-python users from using Diesel as a comet-broker? Why even force python-users to tightly couple their app with Diesel when it'd be so much easier to abstract out the interface they need? provide a service that acts as the master/router for a certain class of messages. Paxos ensures there is only one master elected for every message class, and this router is re-elected should the router go down. The routing table of who is master for what class of messages is kept in sync across all nodes. If you're going to all these lengths then why on earth couple it to a comet server? All these features belong in a message broker, not in a protocol endpoint. You'd make many people happy by building a STOMP or AMQP broker with these features, even people that are not interested in comet at all. Wrt your other reply: No, we don't agree. But at least I have a better idea of what you have in mind now, thanks for that. Also this all is ofcourse just my humble opinion. It's your project and you're free to overengineer at your peril ;-)
- jamwt 17y ago
  Okay, the "comet" bit, I can see that--why conflate those? To clarify--we're going to build a comet framework _on_ diesel, but diesel itself is more of a general async I/O system with cluster messaging features. We intend it to be applicable for building arbitrary networked application using similar patterns to what you'd do in erlang--message passing. We just _happen_ to be focusing on building a comet framework first and foremost on it. That will probably be called "dieselweb". So, the "comet server" portion of our framework may not, in fact, utilize any of this message-broker stuff. But other components might. We're actually going to try to build something fairly unique here, but I don't have all the details ready to put out there yet.
  - moe 17y ago
    Good luck :-)

by jamwt 17y ago

jamwt 17y ago

So, maybe we agree? Because I'm not disputing (and never have) that the message broker is the place to do that. But you seem to be conceptualizing the message broker as a separate _service_ or application, and I'm saying it's just a function, a role. It doesn't matter so much what particular process (or group of processes) it runs in. That's what I meant by "internalize".

moe 17y ago

Every diesel node is an instance of an application You mean one that the user writes (starting with "import diesel")? If so then I'd think such a tight coupling is a bad idea. Why prevent non-python users from using Diesel as a comet-broker? Why even force python-users to tightly couple their app with Diesel when it'd be so much easier to abstract out the interface they need? provide a service that acts as the master/router for a certain class of messages. Paxos ensures there is only one master elected for every message class, and this router is re-elected should the router go down. The routing table of who is master for what class of messages is kept in sync across all nodes. If you're going to all these lengths then why on earth couple it to a comet server? All these features belong in a message broker, not in a protocol endpoint. You'd make many people happy by building a STOMP or AMQP broker with these features, even people that are not interested in comet at all. Wrt your other reply: No, we don't agree. But at least I have a better idea of what you have in mind now, thanks for that. Also this all is ofcourse just my humble opinion. It's your project and you're free to overengineer at your peril ;-)

jamwt 17y ago
Okay, the "comet" bit, I can see that--why conflate those? To clarify--we're going to build a comet framework _on_ diesel, but diesel itself is more of a general async I/O system with cluster messaging features. We intend it to be applicable for building arbitrary networked application using similar patterns to what you'd do in erlang--message passing. We just _happen_ to be focusing on building a comet framework first and foremost on it. That will probably be called "dieselweb". So, the "comet server" portion of our framework may not, in fact, utilize any of this message-broker stuff. But other components might. We're actually going to try to build something fairly unique here, but I don't have all the details ready to put out there yet.
- moe 17y ago
  Good luck :-)