On Wednesday, 12 November 2014 01:11:54 UTC+1, Ben Noordhuis wrote: > > On Tue, Nov 11, 2014 at 12:04 PM, Andreas Marschke > <[email protected] <javascript:>> wrote: > > Hi Ben, > > > > thanks for your pointers. > > > > The fact that I need an API-key and have to (If I understand you > correctly) > > still send my data to the service provider (in worst case > > even through the same network interface as my data I need to process > comes > > in from) means I still have no control over my data > > and sorry but some more security conscious potential customers may take > an > > issue with that. Besides the fact that I'll have to > > doubly saturate my existing bandwidth to get it somehwere else is > slightly > > questionable. What I actually meant by "master of > > my own data" (granted the terminology is a bit messy here) is 1) I keep > my > > data on my premises and get to validate and evaluate > > it myself. A solution (and still use StrongLoop) would be providing an > > appliance or installation package for "on-premise" deployment > > for StrongLoop. > > Maybe I didn't explain it well but in metrics-only mode, no data is > sent to our collector. Basically, the agent collects metrics > in-process and your agent.use() callback is the data sink. We have > more advanced options for clustered applications but that's the basic > mode of operation. > > Ah my bad. But thanks for the information I will check it out. Thanks.
> > Since you said that the landscape is "scattered" regarding performance > and > > profiling and the like. Would it be an improvement to > > commence something like a roundtable of the elders to start "Working > Group" > > or (in theory more agile than a committee) that would > > define, support and create standards as to what to profile? Maybe even > ask > > people from the Companies in the community (ie. > > yourself and breatheren) with blink/v8/node developers together and > think of > > a proper way to guide community as a whole towards > > a common goal of a good standard and development of good tools. I've > seen it > > work for years in the networking community (see > > RIPE working groups) sure there will be the occasional vitriol and > > unnecessary bikeshedding but if it helps more than a handful of > > developers to better understand the node environment from a performance > > point of view. This could be a sister project to what has > > been instantiated next to the recently unveiled nodejs group. > > There was a "birds of a feather" session in Vancouver in August; my > co-worker Sam represented StrongLoop. > > To the best of my knowledge, not much came of it and I suspect that's > because there is not much overlap in the wants and needs of the > stakeholders. About the only thing everyone could agree on is that it > would be great if we don't have to monkey-patch everything when > instrumenting applications and that is what Trevor Norris's > async-listener work is trying to do. > > The fact that you came to no consensus during the discussion makes me wonder how the BoF worked and/or how you went about finding consensus. Sure existing tools that could be improved are always there. But the question is can you with an acceptable amount of effort improve them to service the whole or most parts of the node-community. The much more (to me at least) frustrating thing about this is that node as a scripting language is not the first to experience these painpoints and surely will not be the last. And I cannot imagine that 99% of the able-minded community around NodeJS came from wrinting Jquery to writing Node all day. (Not to undermine or devalue those who HAVE come from a pure Web-Development Background). Most of us have (IME) either a CS-Degree or some form of former knowledge towards these things and have seen other projects/languages struggle under similar conditions in other areas. More to the point: Given that Node/Javascript -- and v8 for that matter -- came from a Frontend World where performance is king especially when improving on a byte-level what has been (sometimes) ruined on the BL-level, it bogels my mind that there are not much else except the Webtoolkit from Blink/Webkit to understand what was wrong. The question is too how much of what is to be analysed and understood is actually Node and not v8 and how have v8-developers been standing towards this issue? > The situation is different from node-forward. With that project, it's > clear what the problems are that need to be addressed, and there is > broad consensus on how to make it happen. > I'll have a look at node-forward. Granted it is not necessarily performance focused but being a sort of self-help/support-group makes it kind of worthwhile to be checked out, -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/c7f6a529-64d1-4cca-aecf-5833897a8e33%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
