openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Thömmes <markusthoem...@me.com>
Subject Re: Allow actions to be accessible from a web browser
Date Fri, 13 Jan 2017 08:55:45 GMT
@Jeremias: From the user's point of view, the invocation is "anonymous". In fact, this means:
The owner of the action pays and throttles of that owner apply as usual.

Relevant code to be found here: https://github.com/openwhisk/openwhisk/pull/1715/commits/d493f0d00cd4597a628fccc939f2abed8a0a8b1a#diff-3df52c74d5f76d4c93f797d24bfd205eR257

Cheers
- mt

Am 13. Januar 2017 um 09:44 schrieb Jeremias Werner <jeremias.werner@gmail.com>:

sorry, I meant anonymous (not asynchronous)

On Fri, Jan 13, 2017 at 9:38 AM, Jeremias Werner <jeremias.werner@gmail.com>
wrote:

Hi,

nice idea. you said, the activations are invoked asynchronous. how does
throttling work for those?

- jeremias

On Fri, Jan 13, 2017 at 8:54 AM, Michael M Behrendt <
Michaelbehrendt@de.ibm.com> wrote:

> i like that this gives me a stable/predictable route, so that i don't
have
to keep around a registry of endpoints in my deployment scripts -- as i
would if the routes were exposed with a random-ish hash in them.

where do you get random-ish hashes today? you mean the api gw integration?
If so, I agree that is sub-optimal and should be addressed there as well.




From: Nick Mitchell <moosevan@gmail.com>
To: dev@openwhisk.apache.org
Date: 01/13/2017 12:21 AM
Subject: Re: Allow actions to be accessible from a web browser



i like that this gives me a stable/predictable route, so that i don't have
to keep around a registry of endpoints in my deployment scripts -- as i
would if the routes were exposed with a random-ish hash in them.

and i like the idea of a simple way of supporting client applications that
doesn't require an extra step in deployment scripts. i.e. i just tack a
`-a
export true` on to the create/update steps.

i also like the ability to do simple projections, thus avoiding the need
for `jq` postprocessing. if i project a field, do i also have to type it,
e.g. /field/x/int? or are the mime types only needed when you want to
force
a non-default interpretation?

using mime types to request a particular response header is pretty
awesome!
though perhaps its use may be somewhat constrained (until we have
streaming?) by any payload limitations a whisk installation might have in
place.

On Thu, Jan 12, 2017 at 5:51 PM, Markus Thömmes <markusthoemmes@me.com>
wrote:

> Haven't looked at the implementation yet but I really dig the idea!
>
> Are query parameters forwarded to the action as well?
>
> - mt
>
> Von meinem iPhone gesendet
>
> > Am 12.01.2017 um 23:44 schrieb Rodric Rabbah <rodric@gmail.com>:
> >
> > I just opened a pull request to allow actions to be accessible viaa
web
> > browser. Action invokes this way are anonymous in that the caller is
not
> > authenticated. The intended action must be named in the path as a
fully
> > qualified name as in
> > /experimental/web/some-namespace/some-package/some-action. The
package
> is
> > optional in that the action may be in the default package. In which
case,
> > the string "default" must be used.
> >
> > If the action doesn't exist (or the namespace is not valid) a
BadRequest
> is
> > generated. Optionally, the result form the action may be projected
based
> on
> > a named property. As in
> >
/experimental/web/some-namespace/some-package/some-action/some-property.
> If
> > the property
> > does not exist in the result then a BadRequest is generated. By
> convention,
> > the "html" property will attempt to respond with media type
"text/html".
> >
> > Actions may be exposed to this web proxy by adding an annotation
> ("export"
> > -> true).
> > Demo video https://ibm.box.com/s/5c6ignvejihbai3f59uvqcxee9etf0lf.
> >
> > Feedback solicited and welcomed.
> >
> > -r
>







Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
    • Unnamed multipart/related (inline, None, 0 bytes)
View raw message