On Fri, Jun 18, 2010 at 1:37 PM, Peter Alexander vel.ac...@gmail.com
wrote:
John I agree, and along the same accord I'd like to mention J. Paul
Morrison [1] and Flow Based Programming [2].
Thanks for the pointer to FBP, it's an interesting read.
-Pieter
Let me add a pointer to an
Matt,
Scaling can be done as long as the dynamic addition/subtraction of
service endpoints does not result in duplication, which can be done
with an appropriate multi-phase protocol to manage the split/join
operations.
Yes. However, split/join operation cannot be done solely on 0MQ
On Jun 22, 2010, at 3:24 AM, Martin Sustrik wrote:
Matt,
Scaling can be done as long as the dynamic addition/subtraction of
service endpoints does not result in duplication, which can be done
with an appropriate multi-phase protocol to manage the split/join
operations.
Yes. However,
Does that mean you have a cluster of components that processes requests
of type X, another cluster that processes requests of type Y and so on?
Not really, I think. Here's a simplified picture:
+--+ +-+
| Read from DB || Sum |+
+--+ +-+|
Douglas,
Does that mean you have a cluster of components that processes requests
of type X, another cluster that processes requests of type Y and so on?
Not really, I think. Here's a simplified picture:
+--+ +-+
| Read from DB || Sum |+
+--+
On Jun 21, 2010, at 10:34 AM, Martin Sustrik wrote:
Douglas,
Does that mean you have a cluster of components that processes
requests
of type X, another cluster that processes requests of type Y and
so on?
Not really, I think. Here's a simplified picture:
+--+
Ok. I see. So basically, you want messages to be load-balanced by 0MQ
but at the same time ensure that all messages with a particular
subject (whatever that means) go to the same downstream component.
Yep, that's the behavior we need — though I should say that I'm not
necessarily asking that
Message-
From: zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of Martin Sustrik
Sent: Friday, June 18, 2010 7:07
To: 0MQ development list
Subject: Re: [zeromq-dev] ooc bindings for ØMQ
Pieter Hintjens wrote:
Yes, and it's amazing no-one already
Peter,
The FBP book [1] is a rigid read but if the concept of visual
programming is familiar to anyone, then you can you can easily
understand the concept of FBP. It does not have to have an interactive
visual front-end, and any front-end component connector (scheduler)
will do. Obviously,
If you have theoretical background in this area, please do check
UPSTREAM/DOWNSTEAM sockets and let me know if you believe something is
broken or missing there.
The first is a very flexible, even autonomous load
distribution/balancing scheme(s) that take into consideration various
aspects
Hi everyone,
I have created ooc bindings for the ØMQ messaging kernel. They're available
on GitHub, under a BSD license:
github.com/nddrylliog/ooc-zeromq
There's the 'Multithreaded server in 10 minutes' example ported to ooc:
github.com/nddrylliog/ooc-zeromq/blob/master/samples/client.ooc
Hi Amos!
I have created ooc bindings for the ØMQ messaging kernel. They're
available on GitHub, under a BSD license:
github.com/nddrylliog/ooc-zeromq http://github.com/nddrylliog/ooc-zeromq
There's the 'Multithreaded server in 10 minutes' example ported to ooc:
At Thu, 17 Jun 2010 11:11:34 +0200, Martin Sustrik wrote:
I have also created a page on the ØMQ website to describe these bindings:
www.zeromq.org/bindings:ooc http://www.zeromq.org/bindings:ooc
Very nice!
In nearest future: ØMQ. The only way to communicate your
applications. ;)
--
At Thu, 17 Jun 2010 11:24:25 +0200, Amos Wenger wrote:
Hehe =) ØMQ looks very interesting indeed, that's one of the reasons I was
motivated to write bindings for it.
The API is simple and no-nonsense, plus it's nice to use in an OO manner.
I may use it in the future to communicate
Aww c'mon: www.zeromq.org/blog:multithreading-magic
(Also, by 'your' I referred to 'whoever writes on the zeromq blog', not
specifically you, Vitaly. Sorry for the confusion)
On Thu, Jun 17, 2010 at 11:32 AM, Vitaly Mayatskikh
v.mayats...@gmail.comwrote:
At Thu, 17 Jun 2010 11:24:25 +0200,
Vitaly Mayatskikh wrote:
In nearest future: ØMQ. The only way to communicate your
applications. ;)
:)
But yes, right. If you think of it, if you want to communicate between
random language X and random language Y (not even speaking of different
OS platforms), 0MQ is often the only choice.
At Thu, 17 Jun 2010 11:37:33 +0200, Amos Wenger wrote:
Aww c'mon: www.zeromq.org/blog:multithreading-magic
(Also, by 'your' I referred to 'whoever writes on the zeromq blog', not
specifically you, Vitaly. Sorry for the confusion)
This it Pieter's article. I only contribute to common lisp
At Thu, 17 Jun 2010 12:28:06 +0200, Pieter Hintjens wrote:
Congratulations on contributing the sixteenth (!) language binding for
0MQ and extra marks for porting the example.
I found one more here:
http://github.com/tybor/Liberty/tree/master/src/wrappers/zmq/
--
wbr, Vitaly
On Thu, Jun 17, 2010 at 1:02 PM, Vitaly Mayatskikh
v.mayats...@gmail.com wrote:
Congratulations on contributing the sixteenth (!) language binding for
0MQ and extra marks for porting the example.
I found one more here:
http://github.com/tybor/Liberty/tree/master/src/wrappers/zmq/
And
On Thu, Jun 17, 2010 at 11:39 AM, Martin Sustrik sust...@250bpm.com wrote:
But yes, right. If you think of it, if you want to communicate between
random language X and random language Y (not even speaking of different
OS platforms), 0MQ is often the only choice.
It becomes compellingly easy
Pieter Hintjens wrote:
It would be wrong IMO to say that having a standard protocol is a bad
thing. HTTP, TCP, IP,... the list of standard protocols with
extensive language support is massive.
I haven't suggested that wire protocol is a bad thing :)
Simply, in the initial stage, wrapping
On Thu, Jun 17, 2010 at 2:04 PM, Martin Sustrik sust...@250bpm.com wrote:
I haven't suggested that wire protocol is a bad thing :)
Simply, in the initial stage, wrapping existing C APIs seems to grow the
community much faster than any wire protocol would be able to.
This is certainly true...
IMO
The key patterns for 0MQ are (among others): lightweight, simplicity,
non-intrusive, low-maintenance, high-performance, efficient,
transparent. I suppose you could call the assemblage the 0MQ
Philosophy.
This if very reminiscent of the core Unix experience vs. Multics, the
enemy at
Matt,
The key patterns for 0MQ are (among others): lightweight, simplicity,
non-intrusive, low-maintenance, high-performance, efficient,
transparent. I suppose you could call the assemblage the 0MQ
Philosophy.
I would add few Internet principles to the mix... no central authority,
On Thu, Jun 17, 2010 at 10:59 PM, Brian Granger elliso...@gmail.com wrote:
Now, if you truly want to define 0MQ as a standard way of communicating
across applications / languages / Oss, then yes, you need to standardize the
data representation. I personally believe this road leads to
On Fri, Jun 18, 2010 at 7:11 AM, Pieter Hintjens p...@imatix.com wrote:
On Thu, Jun 17, 2010 at 10:59 PM, Brian Granger elliso...@gmail.com wrote:
Now, if you truly want to define 0MQ as a standard way of communicating
across applications / languages / Oss, then yes, you need to standardize
Interestingly, Unix pipes don't really either. We've been packetized
for years in the form of lines on Unix.
I'm thinking of writing a pipe adapter for zmq, e.g.:
zpipe --istream tcp://myhost: | grep -v foobar | zpipe --ostream
tcp://yourhost:
zpipe --sub pgm://whatever --topic
Command line zmq is just... evil :)
- Pieter
Sent from my Android mobile phone.
On Jun 17, 2010 7:18 PM, Matt Weinstein matt_weinst...@yahoo.com wrote:
Interestingly, Unix pipes don't really either. We've been packetized
for years in the form of lines on Unix.
I'm thinking of writing a pipe
28 matches
Mail list logo
