Hello all
Let's assume you have an API that results in a batch of HTTP calls which
fire async and which are not sequential. A constraint of the API is that
any errors that occur during the calls need to get returned to the user.
How have you customarily designed this?
One idea was something like
Hey Glenn,
For something this complex I think an event emitter may be better suited.
--
Pedro
On Monday, February 25, 2013 at 9:57 AM, Glenn Block wrote:
> Hello all
>
> Let's assume you have an API that results in a batch of HTTP calls which fire
> async and which are not sequential. A co
+1 on event emitter. Callback with an array of errors is not that common.
You should return an event emitter with complete and error events. be aware
that when you emit an 'error' event and no one is listening in the
application exits
2013/2/25 Pedro Teixeira
> Hey Glenn,
>
> For something this
Any plans to support custom require in future? It works in node.js - why
make browser version of `requre` different from its original?
On Saturday, February 23, 2013 4:43:34 AM UTC+4, substack wrote:
>
> browserify v2 was just released! browserify lets you write node-style
> require() calls for
No need for event emitters, you can do this entirely functional. For this
sorts of asynchroneous tasks, the "async" module comes to the rescue.
A possible implementation would use the "queue" function with a high value
for the concurrency of task procession. Whenever an error occurs, or you
re
When I advised using an event emitter, I was referring to the exposed API,
which looked like what Glenn was asking about.
That operation he mentioned can emit several different events throughout time,
and the best fit would be, in my opinion, an event emitter. It's universally
known to node pro
I wrote this to handle such stuff:
https://github.com/kof/do
Possibly I have to add a complete callback for the case one want to when it is
finished and than get the array of errors.
Normally you don't want go further when error is happened.
Am 25.02.2013 um 10:57 schrieb Glenn Block :
> He
I'd happily take a patch to add something to fs-ext. Especially if it comes
with a patch to support gyp :)
On Sun, Feb 24, 2013 at 5:47 PM, Ben Noordhuis wrote:
> On Sun, Feb 24, 2013 at 11:00 PM, Marcel Laverdet
> wrote:
> > others. Really this is something that might just be better off in fs
@Pedro: This is the nice thing about JavaScript, you can handle problems in
lots of different ways. I'm just pointing out one alternative approach.
EventEmitters make a lot more sense when you are trying to make reusable
components, given the (very small) overhead they imply.
On Monday, Februar
We are doing some dark magic upcoming
using https://github.com/bmeck/node-module-system +1 if we can get a
standardized require shim. Does not need to be ours.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You
Thanks Pedro
On Mon, Feb 25, 2013 at 2:16 AM, Pedro Teixeira wrote:
> Hey Glenn,
>
> For something this complex I think an event emitter may be better suited.
>
> --
> Pedro
>
> On Monday, February 25, 2013 at 9:57 AM, Glenn Block wrote:
>
> Hello all
>
> Let's assume you have an API that resul
"Normally you don't want go further when error is happened."
In this case it is acceptable to continue processing as long as you capture
the received errors. If there were a high amt of failures you "might"
consider cancelling though.
On Mon, Feb 25, 2013 at 6:00 AM, Oleg Slobodskoi wrote:
> I
Jose, thanks for the clarification.
Literally right after sending the mail I was thinking I forgot all about
event emitters :-)
In terms of error, are you saying that any time you emit an event called
"Error" the runtime exits if there is no listener?
On Mon, Feb 25, 2013 at 3:12 AM, José F.
yes
http://nodejs.org/api/events.html#events_class_events_eventemitter
2013/2/25 Glenn Block
> Jose, thanks for the clarification.
>
> Literally right after sending the mail I was thinking I forgot all about
> event emitters :-)
>
> In terms of error, are you saying that any time you emit an e
Agreed, sometimes a yes or no question is answered by an error or success in a
callback in node. You don't see this in blocking systems as much because
try/catch is cumbersome but it's fairly common in node.
On Feb 25, 2013, at February 25, 201311:51 AM, Glenn Block
wrote:
> "Normally you don
quoting docs:
When an EventEmitter instance experiences an error, the typical action is
to emit an 'error' event. Error events are treated as a special case in
node. If there is no listener for it, then the default action is to print a
stack trace and exit the program.
2013/2/25 Glenn Block
>
Short answer, most control-flow libraries support grouping and some form of
error coalescing.
Also, you can use stepdown for this. Stepdown supports error coalescing,
and domains for async catching. It also functions by default as an EE as
well:
var $$ = require('stepdown')
function foo(callback
Thanks. I hate to admit I've created emitters before and didn't realize
this.
On Mon, Feb 25, 2013 at 12:00 PM, José F. Romaniello wrote:
> quoting docs:
>
> When an EventEmitter instance experiences an error, the typical action is
> to emit an 'error' event. Error events are treated as a s
Dan,
Thanks for the information... I will knock around and see what I can do
with that approach.
Thanks,
smak
On Friday, February 22, 2013 10:01:45 AM UTC-5, Dan Milon wrote:
>
> It's up to you to filter and validate the input. (ok, mongoose has
> some basic validation but that won't help you
*Can I use NodeJS to detect a upnp device, and send it a SOAP message?*
Currently, I'm using Miranda.py to scan for a UPNP device, and send a SOAP
message, that goes like this in a python shell:
PYTHON:
>>> from miranda import upnp
>>> conn = upnp()
>>> resp = conn.sendSOAP( uri, urn, url, etc
Question to all concerned who are creating these tools that bundle:
How do you handle dependencies in purely client-side code? I built a
little library that uses transitive reduction along with a manifest file
that lists all known dependencies for each of the browser-side scripts, so
for examp
You can try taking this module as a base, and extending it with other
functions: https://github.com/indutny/node-nat-upnp
Cheers,
Fedor.
On Tue, Feb 26, 2013 at 12:52 AM, Tim Montague wrote:
> *Can I use NodeJS to detect a upnp device, and send it a SOAP message?*
>
> Currently, I'm using Mira
2013.02.25, Version 0.8.21 (Stable)
* http: Do not free the wrong parser on socket close (isaacs)
* http: Handle hangup writes more gently (isaacs)
* zlib: fix assert on bad input (Ben Noordhuis)
* test: add TAP output to the test runner (Timothy J Fontaine)
Source Code: http://nodejs.org/dis
Generally I abstract out my implementations and my interfaces. This means a
more verbose code base, but allows me to have the renderer inserted via
dependency injection. It is independent of bundling tech and I have used it
with browserify as well as with AMD to great success. Decoupling those
I've just made the first public release of reStore, a Node.js server that
implements the remoteStorage protocol. This lets web applications delegate
their storage needs to a server chosen by the user, and is part of the
Unhosted project.
http://blog.jcoglan.com/2013/02/25/announcing-restore-a-pers
I'm using node odbc a LOT with db2... it's c++, non blocking and therefore
very fast...
google odbc sap hana...
On Friday, February 22, 2013 4:43:34 PM UTC-5, TJ wrote:
>
> On 22/02/13 20:49, Zhibin wrote:
> > Hi,
> >
> > Is anyone interested to build a node.js database driver for SAP HANA
Jeremy Rudd writes:
> *What:* Can NodeJS apps be distributed as binary? ie. you compile the .js
> app via V8 into its native binary, and distribute the binary to our
> clients? ... or is minifying the code all you can do?
>
> *Why:* We build serverside applications in NodeJS for clients, that h
27 matches
Mail list logo