The Bills mail which will give the context about the feature
I made a bit of a mess of things yesterday in my haste to migrate ThreadManager to PActor. Thanks Vicky for cleaning up some of that mess. I've done a bit more now and PingPong once again compiles.
I think Sebastien is right. Dependency injection will be a great way of handling implementations. This applies to MailboxFactory, JID factories and OSGi. Vicky, please do some digging into Google Guice and peaberry.
For now Sebastien, I would appreciate it if you could finish message buffering. After that there is the option of adding Guice/peaberry and cleaning up MailboxFactory a bit more or proceeding with commandeering. But we also need to discuss synchronous messaging, which has a latency of almost 4 times that of PActor. Perhaps there is a faster way of normalizing control flows that will not be as expensive as a second queue in Mailbox.
I do love the [extreme] separation of API and implementation. And it looks like Guice/peaberry will play into this very nicely. You should also observe that the revised PActor javadocs do not speak so much of implementation particulars now but are much more focused on usage. I believe this not only brings greater clarity, but a degree of freedom when supplying alternative implementations or in subsequent revisions of the default implementation. Decoupling is always best, and Dependency Injection the pain points quite nicely. :-)
laforge49
commented
10 years ago
The Bills mail which will give the context about the feature
I made a bit of a mess of things yesterday in my haste to migrate ThreadManager to PActor. Thanks Vicky for cleaning up some of that mess. I've done a bit more now and PingPong once again compiles.
I think Sebastien is right. Dependency injection will be a great way of handling implementations. This applies to MailboxFactory, JID factories and OSGi. Vicky, please do some digging into Google Guice and peaberry.
For now Sebastien, I would appreciate it if you could finish message buffering. After that there is the option of adding Guice/peaberry and cleaning up MailboxFactory a bit more or proceeding with commandeering. But we also need to discuss synchronous messaging, which has a latency of almost 4 times that of PActor. Perhaps there is a faster way of normalizing control flows that will not be as expensive as a second queue in Mailbox.
I do love the [extreme] separation of API and implementation. And it looks like Guice/peaberry will play into this very nicely. You should also observe that the revised PActor javadocs do not speak so much of implementation particulars now but are much more focused on usage. I believe this not only brings greater clarity, but a degree of freedom when supplying alternative implementations or in subsequent revisions of the default implementation. Decoupling is always best, and Dependency Injection the pain points quite nicely. :-)