inline
On 26/03/2013 04:13 πμ, Isaac Schlueter wrote:
> If you add a `readable` handler, then `'readable'` (and
> potentially `'end'`, if there's no data) will be emitted.
>
>> So the readable event is more of an advisory event. The docs
>> should probably say something about how you could possibly miss
>> the event entirely if you're doing some other IO before you try
>> and read from the stream.
>
> The docs don't say that because it's not true. (Unless, of
> course, someone *else* is listening for it, or reading from it, but
> then it's not really *your* stream, now, is it?)
>
> This is perfectly safe:
>
> ``` net.createServer(function(sock) { doSomeIOandTHEN(function() {
> sock.on('readable', function() { readStuff(sock) }) }) }) ```
>
Could you provide a functional test case where attaching a readable
listener late, works? According to #5141 [1], it doesn't, at least for
http.request.
[1] https://github.com/joyent/node/issues/5141
>> It seems like we get to pick one API or the other. I can make all
>> of my code use the new API or I can abuse the reverse
>> compatibility, either way I'm only using one API.
>
> I don't see how you can call this "abuse", really. It's not as if
> there's "new API" and "old API" living side by side here. There's
> just "The API". It's not bad to use any part of it.
>
> One thing that sort of is unfortunate is that there's no way to
> switch out of flowing-mode (pause/resume) without wrapping. So
> far, this isn't much of a problem, because you usually decide what
> you'er going to do with a stream, and then do it. (Either pipe,
> consume in chunks, or pause/resume/on('data') it.)
>
> So, for a module like request, you probably want to be a bit less
> opinionated. If you know you're going to just collect upthe
> entire response body, and pass to a callback, then fine. But if
> you're going to pass the stream along, then setting it into
> flowing-mode is not so great, because you don't know the user wants
> that.
>
>> Part of the reason I was so excited about streams2 is that I
>> thought it meant I could finally deprecate BufferedStream in
>> favor of 0.10's Readable.
>
> Part of the reason we wrote streams2 was so that you could
> deprecate BufferedStream :)
>
>> streams would spew data regardless of whether or not you had
>> registered for "data" events or called pause().
>
> Both bugs are fixed now.
>
>> But honestly, when you start cracking open node core code just to
>> figure out how things work you start relying on implementation
>> details that may not even be specified fully.
>
> Well, when RTFM doesn't give you the answers you need, then RTFS
> is the next step. It could mean that the docs are lacking, and as
> you know, help is always welcome there. If you find a question
> not answered by the documentation, send a doc patch with the answer
> when you do find it.
>
>> Looking back, the data/pause/resume/end/error API isn't too bad.
>
> And it's still there. It's not wrong to use it. Go nuts, really.
>
>> The main problem with it was that a lot of streams didn't really
>> care if you paused them.
>
> There were other problems as well. Node-core has a ton of
> streams, and each of them had completely different implementations
> of all the streams semantics, with hardly any code reuse at all,
> and in many cases, completely unique and opposite bugs and
> behavior. It was a nightmare to maintain.
>
> Streams are a core API. Like all core APIs, they're a node
> paradigm that it pays to follow and use. But ultimately, like
> callbacks and EventEmitters and all the rest, they're there to
> facilitate the APIs that node presents. If you'd rather build your
> own modules in different ways, go crazy. Really. That's what
> innovation means.
>
>> Related: the most intuitive streams implementation I've ever used
>> is (gasp!) PHP's. You just call fopen with a URL (file://,
>> http://, zlib://, etc.) and boom, you've got a handle to a stream
>> of data that every other function in the stdlib knows how to
>> use.
>
> Well, of course, we're not going to rely on magic strings,
> protocol registration, or have a method called `fopen` that you
> pass http:// urls. That stuff is just completely crazy.
>
> But if you present a stream for anything (say, a file, http, zlib,
> etc.) then you can .pipe() to/from it from/to any other stream.
> If you just use .pipe() (or some data collection method like was
> presented earlier in this thread) then you have a similar sort of
> portability. You can't seek() in streams, but you can read() just
> as many bytes as you like. You can even create your own streams or
> apply as many filters as you like, and have something that
> everything else in the stdlib knows how to deal with.
>
>
>
> On Mon, Mar 25, 2013 at 5:03 PM, Michael Jackson
> <mjijack...@gmail.com> wrote:
>> The use case I always use when testing this kind of thing is
>> http's ClientResponse object. It used to (in the 0.4 days)
>> completely ignore pause(), as did ServerRequest. I wrote
>> BufferedStream so I could just ignore it and move forward.
>> However, ClientResponse seems to be able to pause() just fine in
>> 0.10.
>>
>> I would agree that's it's wise to pick one API or another. These
>> days I'm in the process of upgrading to 0.10 and ditching all my
>> old usage patterns, so that's why I'm running into the corner
>> cases.
>>
>> -- Michael Jackson @mjackson
>>
>>
>> On Mon, Mar 25, 2013 at 4:53 PM, Mikeal Rogers
>> <mikeal.rog...@gmail.com> wrote:
>>>
>>>
>>> On Mar 25, 2013, at 4:40PM, Michael Jackson
>>> <mjijack...@gmail.com> wrote:
>>>
>>> I don't think there's necessarily any *more* confusion over
>>> streams2 than there ever was over old streams, just a different
>>> set of questions to answer.
>>>
>>> Part of the reason I was so excited about streams2 is that I
>>> thought it meant I could finally deprecate BufferedStream in
>>> favor of 0.10's Readable. I wrote BufferedStream back in the
>>> 0.4 days when streams would spew data regardless of whether or
>>> not you had registered for "data" events or called pause(). The
>>> basic idea behind the library was that you could pass whatever
>>> you wanted to the constructor (a stream, a string, a Buffer, or
>>> what have you) and that you would get back a predictable
>>> interface for handling streaming data without losing any
>>> events.
>>>
>>> It was incredibly difficult to get all the semantics of streams
>>> right, but I think we came pretty close. But streams2 opens a
>>> whole new can of worms. Now we're not just keeping
>>> compatibility with the old behavior (well, pausing seems to
>>> work a lot better now)
>>>
>>>
>>> Is this true?
>>>
>>> In request I'm just abusing the backwards compatibility mode by
>>> calling .resume() on stuff a lot.
>>>
>>> In a future release i'll pull in readable-stream and inherit
>>> from it and using the old stream wrappers so that all of
>>> request's code is using the new API.
>>>
>>> It seems like we get to pick one API or the other. I can make
>>> all of my code use the new API or I can abuse the reverse
>>> compatibility, either way I'm only using one API.
>>>
>>> but introducing an entirely new method of consuming streams on
>>> top of that. I've found myself diving into the
>>> _stream_readable.js code a lot more than I would have liked
>>> over the past few weeks just to figure out how things work.
>>> It's an incredibly complex piece of code. Hats off to the core
>>> team - I know how tricky it can get. But honestly, when you
>>> start cracking open node core code just to figure out how
>>> things work you start relying on implementation details that
>>> may not even be specified fully. So it's kind of a precarious
>>> place to be.
>>>
>>> Looking back, the data/pause/resume/end/error API isn't too
>>> bad. The main problem with it was that a lot of streams didn't
>>> really care if you paused them. Fixing that piece and leaving
>>> the rest (buffering, duplex, transform, etc.) up to npm modules
>>> would have been a great baby step without introducing an
>>> entirely new API.
>>>
>>> Related: the most intuitive streams implementation I've ever
>>> used is (gasp!) PHP's. You just call fopen with a URL (file://,
>>> http://, zlib://, etc.) and boom, you've got a handle to a
>>> stream of data that every other function in the stdlib knows
>>> how to use. You can specify custom wrappers that know how to
>>> open different URL schemes, stack as many filters as you like
>>> on top of them. You never need to worry about data events, or
>>> what state different streams are in. You can seek to different
>>> positions in the stream, read just a certain number of bytes,
>>> whatever. It's just super simple and super powerful.
>>>
>>> -- Michael Jackson @mjackson
>>>
>>>
>>> On Mon, Mar 25, 2013 at 2:41 PM, Mikeal Rogers
>>> <mikeal.rog...@gmail.com> wrote:
>>>>
>>>> This thread is pretty huge.
>>>>
>>>> At this point, would people say there is more confusion about
>>>> streams2 than old streams? I know that some of this is a
>>>> little hard to get our heads around but i always got the
>>>> feeling that only about 10 people really understood all of
>>>> old streams.
>>>>
>>>> -Mikeal
>>>>
>>>> On Mar 25, 2013, at 2:40PM, Marco Rogers
>>>> <marco.rog...@gmail.com> wrote:
>>>>
>>>> I'm more and more convinced that need to go back and read all
>>>> the available info about streams2. Answering these detail
>>>> semantics questions is pretty important.
>>>>
>>>> :Marco
>>>>
>>>> On Mon, Mar 25, 2013 at 2:29 PM, Michael Jackson
>>>> <mjijack...@gmail.com> wrote:
>>>>>
>>>>> If stream.read returns null that could mean one of two
>>>>> things:
>>>>>
>>>>> 1) the stream doesn't currently have any data, but still
>>>>> might have some in the future 2) the stream is already
>>>>> ended
>>>>>
>>>>> AFAICT, the only way you can know which state you're in is
>>>>> by checking the stream.readable property which is marked as
>>>>> being a "legacy" property in the code, so it seems like
>>>>> it's not a good idea to rely on that property either.
>>>>>
>>>>> -- Michael Jackson @mjackson
>>>>>
>>>>>
>>>>> On Mon, Mar 25, 2013 at 1:50 PM, Dan Milon
>>>>> <danmi...@gmail.com> wrote:
>>>>>>
>>>>>> You're right, my bad.
>>>>>>
>>>>>> But still, data stay in the buffer until someone tries to
>>>>>> `.read()`. So, if you're being passed a stream that you
>>>>>> dont know whether the first `readable` event has fired,
>>>>>> you can try to actually read from it. If it returns null,
>>>>>> then you wait for `readable`.
>>>>>>
>>>>>> On 03/25/13 22:42, Michael Jackson wrote:
>>>>>>> readable is emitted after you've actually started
>>>>>>> reading.
>>>>>>>
>>>>>>>
>>>>>>> That's not what it says in the docs
>>>>>>> <http://nodejs.org/api/stream.html#stream_event_readable>.
>>>>>>>
>>>>>>>
>>>>>>>
### Event: 'readable' When there is data ready to be consumed,
>>>>>>> this event will fire. When this event emits, call the
>>>>>>> read() method to consume the data. ###
>>>>>>>
>>>>>>> Calling stream.read *before* you get the "readable"
>>>>>>> event is totally counterintuitive.
>>>>>>>
>>>>>>> -- Michael Jackson @mjackson
>>>>>>>
>>>>>>> In your example, you dont ever `response.read()`, so no
>>>>>>> readable event is ever emitted.
>>>>>>>
>>>>>>> As you said, streams start in paused state and ready to
>>>>>>> be read.
>>>>>>>
>>>>>>> On 03/25/13 22:28, Michael Jackson wrote:
>>>>>>>> Is it correct to assume that a Readable won't emit
>>>>>>>> the "readable"
>>>>>>> event
>>>>>>>> until you're registered for it?
>>>>>>>>
>>>>>>>> Reading through the streams2 docs, I was under the
>>>>>>>> impression that all streams start out paused and
>>>>>>>> don't start emitting data until you add either a
>>>>>>>> "data" (for old streams) or a "readable" listener.
>>>>>>>> For new streams, this should mean that they don't
>>>>>>>> emit "readable" until at
>>>>>>> least
>>>>>>>> one listener is registered. Otherwise we still need
>>>>>>>> to do some
>>>>>>> buffering
>>>>>>>> in order to capture all the data.
>>>>>>>>
>>>>>>>> For example, this code misses the readable event on
>>>>>>>> node 0.10:
>>>>>>>>
>>>>>>>> var http = require('http');
>>>>>>>>
>>>>>>>> http.get('http://www.google.com', function (response)
>>>>>>>> { console.log('got response with status ' +
>>>>>>>> response.statusCode);
>>>>>>>>
>>>>>>>> setTimeout(function () { response.on('readable',
>>>>>>>> function () { console.log('readable'); });
>>>>>>>>
>>>>>>>> response.on('end', function () { console.log('end');
>>>>>>>> }); }, 5); });
>>>>>>>>
>>>>>>>> Here's my shell session:
>>>>>>>>
>>>>>>>> $ node -v v0.10.0 $ node http-test.js got response
>>>>>>>> with status 200 $
>>>>>>>>
>>>>>>>> Is this the correct behavior?
>>>>>>>>
>>>>>>>> -- Michael Jackson @mjackson
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 21, 2013 at 4:27 PM, Isaac Schlueter
>>>>>>>> <i...@izs.me
>>>>>>> <mailto:i...@izs.me>
>>>>>>>> <mailto:i...@izs.me <mailto:i...@izs.me>>> wrote:
>>>>>>>>
>>>>>>>> re old-mode
>>>>>>>>
>>>>>>>> Yes, that's fine. If you just want to get all the
>>>>>>>> data asap, use on('data', handler). It'll work
>>>>>>>> great, and it's still very fast. pause()/resume(),
>>>>>>>> the whole bit. (The difference is that it won't emit
>>>>>>>> data until you're listening, and pause() will
>>>>>>>> *actually*
>>>>>>> pause.)
>>>>>>>>
>>>>>>>>
>>>>>>>> Re read(cb)
>>>>>>>>
>>>>>>>> It's problematic for reasons that I've discussed all
>>>>>>>> of the places where it's been brought up. That horse
>>>>>>>> is dead, let's stop
>>>>>>> beating
>>>>>>>> it. (There were a few other proposals as well, btw.
>>>>>>> Reducibles and
>>>>>>>> some other monadic approaches come to mind.)
>>>>>>>>
>>>>>>>>
>>>>>>>> Re pipe() vs looping around read() vs custom Writable
>>>>>>>> vs
>>>>>>> on('data')
>>>>>>>>
>>>>>>>> Whatever works for your case is fine. It's flexible
>>>>>>>> on
>>>>>>> purpose, and
>>>>>>>> allows more types of consumption than streams1, and
>>>>>>>> creating
>>>>>>> custom
>>>>>>>> writables is easier than it was in streams1.
>>>>>>>>
>>>>>>>> If you find something that the API can't do for you,
>>>>>>>> or find
>>>>>>> yourself
>>>>>>>> doing a lot of backflips or overriding a lot of
>>>>>>>> methods to get
>>>>>>> your
>>>>>>>> stuff working, then let's chat about it in a github
>>>>>>>> issue.
>>>>>>> You might
>>>>>>>> be missing something, or you might have found a
>>>>>>>> genuine
>>>>>>> shortcoming in
>>>>>>>> the API.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 21, 2013 at 2:01 PM, Sigurgeir Jonsson
>>>>>>>> <ziggy.jonsson....@gmail.com
>>>>>>> <mailto:ziggy.jonsson....@gmail.com>
>>>>>>> <mailto:ziggy.jonsson....@gmail.com
>>>>>>> <mailto:ziggy.jonsson....@gmail.com>>>
>>>>>>>> wrote:
>>>>>>>>> Thanks for all the answers. I almost forgot to look
>>>>>>>>> back at this
>>>>>>>> thread as
>>>>>>>>> the custom writeStreams have exceeded the high
>>>>>>>>> expectation I had
>>>>>>>> already for
>>>>>>>>> Streams 2. For me, the reference manual was a
>>>>>>>>> little confusing, as
>>>>>>> there are
>>>>>>>> complete
>>>>>>>>> examples on using the read method, no mention of
>>>>>>>>> "reading"
>>>>>>> through a
>>>>>>>>> writeStream endpoint.
>>>>>>>>>
>>>>>>>>> Marco, I agree that that read has more detailed
>>>>>>>>> control of
>>>>>>> minimum
>>>>>>>> incoming
>>>>>>>>> content. However I wonder if it would be more
>>>>>>>>> efficient to
>>>>>>> default
>>>>>>>>> pipe.chunkSize to a "lowWatermark" of the receiver
>>>>>>>>> (if defined).
>>>>>>>> This
>>>>>>>>> lowWatermark could be adjusted dynamically and the
>>>>>>>>> callback
>>>>>>> in the
>>>>>>>> writable
>>>>>>>>> should keep sequence of events under control?
>>>>>>>>>
>>>>>>>>> Anyway, thanks Node team, I'm very impressed!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wednesday, March 20, 2013 4:45:32 AM UTC-4,
>>>>>>>>> Marco Rogers
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> @Nathan's response is right. Creating a writable
>>>>>>>>>> stream is
>>>>>>>> preferable in
>>>>>>>>>> most cases. But I wanted to add a little context
>>>>>>>>>> to that. If
>>>>>>>> you're dealing
>>>>>>>>>> with a base readable stream, it's just pushing
>>>>>>>>>> chunks of
>>>>>>> data at
>>>>>>>> you off the
>>>>>>>>>> wire. Your first task is to collect those chunks
>>>>>>>>>> into
>>>>>>> meaningful
>>>>>>>> data. So
>>>>>>>>>> IMO the reason creating a writable stream is
>>>>>>>>>> preferable is
>>>>>>> because it
>>>>>>>>>> prompts you not just read off the stream, but to
>>>>>>>>>> create
>>>>>>> semantics
>>>>>>>> around
>>>>>>>>>> what the new stream is supposed to be. The api
>>>>>>>>>> reflects this
>>>>>>>> opinion and
>>>>>>>>>> that's why creating writable streams feels like
>>>>>>>>>> the more
>>>>>>> natural
>>>>>>>> way, and
>>>>>>>>>> the ugliness of dealing with read() is wrapped up
>>>>>>>>>> in the pipe()
>>>>>>>> method. It
>>>>>>>>>> was kind of designed that way.
>>>>>>>>>>
>>>>>>>>>> But the read() api was also designed for a use
>>>>>>>>>> case. It's meant
>>>>>>>> to handle
>>>>>>>>>> low/high water marks effectively, as well as
>>>>>>>>>> enable more
>>>>>>>> optimized special
>>>>>>>>>> parsing by reading off specific lengths of
>>>>>>>>>> chunks. These were
>>>>>>>> things that
>>>>>>>>>> people kept needing, but the old api didn't
>>>>>>>>>> support well.
>>>>>>> If you were
>>>>>>>>>> writing a library for a special parser, you might
>>>>>>>>>> write a
>>>>>>> custom
>>>>>>>> Writable
>>>>>>>>>> stream and inside it you would be using the
>>>>>>>>>> read(n) api to
>>>>>>>> control *how* you
>>>>>>>>>> read data off the socket. I hope that makes
>>>>>>>>>> sense.
>>>>>>>>>>
>>>>>>>>>> :Marco
>>>>>>>>>>
>>>>>>>>>> On Monday, March 18, 2013 11:06:48 AM UTC-7,
>>>>>>>>>> Sigurgeir
>>>>>>> Jonsson wrote:
>>>>>>>>>>>
>>>>>>>>>>> The new streams have excellent support for
>>>>>>>>>>> high/low
>>>>>>> watermarks and
>>>>>>>>>>> auto-pausing/resuming, but the documentation
>>>>>>>>>>> confuses me a
>>>>>>> little...
>>>>>>>>>>> particularly the read method.
>>>>>>>>>>>
>>>>>>>>>>> When I read the new docs for the first time I
>>>>>>>>>>> was under the
>>>>>>>> impression
>>>>>>>>>>> that the optimal way to become a user of a
>>>>>>>>>>> stream is to write
>>>>>>>> loops around
>>>>>>>>>>> the read functio. However in practice I find
>>>>>>>>>>> myself simply
>>>>>>>> writing custom
>>>>>>>>>>> writeStreams and use the callback to control
>>>>>>>>>>> upstream pressure
>>>>>>>> (in addition
>>>>>>>>>>> to source Watermarks if needed). Here is an
>>>>>>>>>>> example where I
>>>>>>>> move the
>>>>>>>>>>> output to a queue that executes a custom
>>>>>>>>>>> function in
>>>>>>> parallel (i.e.
>>>>>>>>>>> uploading to a database)
>>>>>>> https://gist.github.com/ZJONSSON/5189249
>>>>>>>>>>>
>>>>>>>>>>> Are there any benefits to using the read method
>>>>>>>>>>> directly on a
>>>>>>>> stream vs.
>>>>>>>>>>> piping to a custom Writable stream?
>>>>>>>>>
>>>>>>>>> -- -- Job Board: http://jobs.nodejs.org/ Posting
>>>>>>>>> guidelines:
>>>>>>>>>
>>>>>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>
You received this message because you are subscribed to the
>>>>>>> Google
>>>>>>>>> Groups "nodejs" group. To post to this group, send
>>>>>>>>> email to nodejs@googlegroups.com
>>>>>>> <mailto:nodejs@googlegroups.com>
>>>>>>>> <mailto:nodejs@googlegroups.com
>>>>>>>> <mailto:nodejs@googlegroups.com>>
>>>>>>>>> To unsubscribe from this group, send email to
>>>>>>>>> nodejs+unsubscr...@googlegroups.com
>>>>>>> <mailto:nodejs%2bunsubscr...@googlegroups.com>
>>>>>>>> <mailto:nodejs%2bunsubscr...@googlegroups.com
>>>>>>> <mailto:nodejs%252bunsubscr...@googlegroups.com>>
>>>>>>>>> For more options, visit this group at
>>>>>>>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>>>>>>>
>>>>>>>>> --- You received this message because you are
>>>>>>>>> subscribed to the
>>>>>>> Google
>>>>>>>> Groups
>>>>>>>>> "nodejs" group. To unsubscribe from this group and
>>>>>>>>> stop receiving emails
>>>>>>> from it,
>>>>>>>> send an
>>>>>>>>> email to nodejs+unsubscr...@googlegroups.com
>>>>>>> <mailto:nodejs%2bunsubscr...@googlegroups.com>
>>>>>>>> <mailto:nodejs%2bunsubscr...@googlegroups.com
>>>>>>> <mailto:nodejs%252bunsubscr...@googlegroups.com>>.
>>>>>>>>> For more options, visit
>>>>>>> https://groups.google.com/groups/opt_out.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> -- -- Job Board: http://jobs.nodejs.org/ Posting
>>>>>>>> guidelines:
>>>>>>>>
>>>>>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>>
You received this message because you are subscribed to the
>>>>>>> Google
>>>>>>>> Groups "nodejs" group. To post to this group, send
>>>>>>>> email to nodejs@googlegroups.com
>>>>>>> <mailto:nodejs@googlegroups.com>
>>>>>>>> <mailto:nodejs@googlegroups.com
>>>>>>>> <mailto:nodejs@googlegroups.com>> To unsubscribe from
>>>>>>>> this group, send email to
>>>>>>>> nodejs+unsubscr...@googlegroups.com
>>>>>>> <mailto:nodejs%2bunsubscr...@googlegroups.com>
>>>>>>>> <mailto:nodejs%2bunsubscr...@googlegroups.com
>>>>>>> <mailto:nodejs%252bunsubscr...@googlegroups.com>>
>>>>>>>> For more options, visit this group at
>>>>>>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>>>>>>
>>>>>>>> --- You received this message because you are
>>>>>>>> subscribed to the Google Groups "nodejs" group. To
>>>>>>>> unsubscribe from this group and stop receiving emails
>>>>>>>> from it, send an email to
>>>>>>>> nodejs+unsubscr...@googlegroups.com
>>>>>>> <mailto:nodejs%2bunsubscr...@googlegroups.com>
>>>>>>>> <mailto:nodejs%2bunsubscr...@googlegroups.com
>>>>>>> <mailto:nodejs%252bunsubscr...@googlegroups.com>>.
>>>>>>>> For more options, visit
>>>>>>>> https://groups.google.com/groups/opt_out.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -- -- Job Board: http://jobs.nodejs.org/ Posting
>>>>>>>> guidelines:
>>>>>>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>>
You received this message because you are subscribed to the Google
>>>>>>>> Groups "nodejs" group. To post to this group, send
>>>>>>>> email to nodejs@googlegroups.com
>>>>>>> <mailto:nodejs@googlegroups.com>
>>>>>>>> To unsubscribe from this group, send email to
>>>>>>>> nodejs+unsubscr...@googlegroups.com
>>>>>>> <mailto:nodejs%2bunsubscr...@googlegroups.com>
>>>>>>>> For more options, visit this group at
>>>>>>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>>>>>>
>>>>>>>> --- You received this message because you are
>>>>>>>> subscribed to the Google Groups "nodejs" group. To
>>>>>>>> unsubscribe from this group and stop receiving emails
>>>>>>>> from it, send an email to
>>>>>>>> nodejs+unsubscr...@googlegroups.com
>>>>>>> <mailto:nodejs%2bunsubscr...@googlegroups.com>.
>>>>>>>> For more options, visit
>>>>>>>> https://groups.google.com/groups/opt_out.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -- -- Job Board: http://jobs.nodejs.org/ Posting
>>>>> guidelines:
>>>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>>>>
>>>>>
You received this message because you are subscribed to the Google
>>>>> Groups "nodejs" group. To post to this group, send email to
>>>>> nodejs@googlegroups.com To unsubscribe from this group,
>>>>> send email to nodejs+unsubscr...@googlegroups.com For more
>>>>> options, visit this group at
>>>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>>>
>>>>> --- You received this message because you are subscribed to
>>>>> a topic in the Google Groups "nodejs" group. To unsubscribe
>>>>> from this topic, visit
>>>>> https://groups.google.com/d/topic/nodejs/8VGu32aczR0/unsubscribe?hl=en.
>>>>>
>>>>>
To unsubscribe from this group and all its topics, send an email to
>>>>> nodejs+unsubscr...@googlegroups.com. For more options,
>>>>> visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -- Marco Rogers marco.rog...@gmail.com |
>>>> https://twitter.com/polotek
>>>>
>>>> Life is ten percent what happens to you and ninety percent
>>>> how you respond to it. - Lou Holtz
>>>>
>>>> -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines:
>>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>>>
>>>>
You received this message because you are subscribed to the Google
>>>> Groups "nodejs" group. To post to this group, send email to
>>>> nodejs@googlegroups.com To unsubscribe from this group, send
>>>> email to nodejs+unsubscr...@googlegroups.com For more
>>>> options, visit this group at
>>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>>
>>>> --- You received this message because you are subscribed to
>>>> the Google Groups "nodejs" group. To unsubscribe from this
>>>> group and stop receiving emails from it, send an email to
>>>> nodejs+unsubscr...@googlegroups.com. For more options, visit
>>>> https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines:
>>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>>>
>>>>
You received this message because you are subscribed to the Google
>>>> Groups "nodejs" group. To post to this group, send email to
>>>> nodejs@googlegroups.com To unsubscribe from this group, send
>>>> email to nodejs+unsubscr...@googlegroups.com For more
>>>> options, visit this group at
>>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>>
>>>> --- You received this message because you are subscribed to
>>>> the Google Groups "nodejs" group. To unsubscribe from this
>>>> group and stop receiving emails from it, send an email to
>>>> nodejs+unsubscr...@googlegroups.com. For more options, visit
>>>> https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>>
>>>
>>>
>>> -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines:
>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>>
>>>
You received this message because you are subscribed to the Google
>>> Groups "nodejs" group. To post to this group, send email to
>>> nodejs@googlegroups.com To unsubscribe from this group, send
>>> email to nodejs+unsubscr...@googlegroups.com For more options,
>>> visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>
>>> --- You received this message because you are subscribed to the
>>> Google Groups "nodejs" group. To unsubscribe from this group
>>> and stop receiving emails from it, send an email to
>>> nodejs+unsubscr...@googlegroups.com. For more options, visit
>>> https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>>
>>> -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines:
>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>>
>>>
You received this message because you are subscribed to the Google
>>> Groups "nodejs" group. To post to this group, send email to
>>> nodejs@googlegroups.com To unsubscribe from this group, send
>>> email to nodejs+unsubscr...@googlegroups.com For more options,
>>> visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>
>>> --- You received this message because you are subscribed to the
>>> Google Groups "nodejs" group. To unsubscribe from this group
>>> and stop receiving emails from it, send an email to
>>> nodejs+unsubscr...@googlegroups.com. For more options, visit
>>> https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
>> -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>
>>
You received this message because you are subscribed to the Google
>> Groups "nodejs" group. To post to this group, send email to
>> nodejs@googlegroups.com To unsubscribe from this group, send
>> email to nodejs+unsubscr...@googlegroups.com For more options,
>> visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> --- You received this message because you are subscribed to the
>> Google Groups "nodejs" group. To unsubscribe from this group and
>> stop receiving emails from it, send an email to
>> nodejs+unsubscr...@googlegroups.com. For more options, visit
>> https://groups.google.com/groups/opt_out.
>>
>>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
