I haven’t heard anyone ask for this, but there is no reason it should not be
possible to extract an interface for messaging; in fact it is mostly there
already (see whisk.core.connector.MessageProducer), except for the binding
aspect. Have you already implemented an alternate MessageProducer imp
On Fri, Jun 9, 2017 at 7:54 PM, Tyson Norris wrote:
> Hi -
> I’ve seen the need for portions of OpenWhisk to be more “pluggable”, and seen
> similar comments in GitHub and dev list.
>
> Some areas I think are worthy of discussion are:
> - tracing
> - logging
> - container management (docker, runc
I would phrase things slightly different
"there's no runtime DI framework for Scala out the shelf “ => I don’t think
that’s exactly true, some discussion is here:
http://letitcrash.com/post/55958814293/akka-dependency-injection
But providing an SPI is different than adopting dependency injection
"...To make any progress on anything being pluggable, one approach is to
provide a convention for doing the plugging"
So we're basically saying there's no runtime DI framework for Scala out the
shelf and we need to come up with one ? It's fine if we do, but it would be
great to list our as
> it would be great if there was also a performance test case that simulates
> the traffic patterns you have in mind.
The pathology that this improvement addresses is quite intuitive to understand,
in absence of a benchmark or performance test. That said, I do think we have
broad agreement amo
Hi Markus,
I like the approach you have taken. Here’s a more general comment (relevant not
to only this PR):
The stated motivation for the PR is to improve performance. I have no doubt
that the (average) performance of action invocation is increased by this PR for
most relevant traffic patterns
I think 'low hanging fruit' is a good idea,
just need to document it in some place for new comers to understand the
meanings.
Best regards
Ying Chun Guo (Daisy)
-"Matt Rutkowski" wrote: -
To: dev@openwhisk.apache.org
From: "Matt Rutkowski"
Date: 06/12/2017 09:25PM
Subject: Re: Reques
