rabbah opened a new issue #4637: inefficiencies and issues with the actions 
URL: https://github.com/apache/openwhisk/issues/4637
   Actions are represented by the type `WhiskAction`, which includes a property 
of type `Exec`. The `Exec` instances may include the code inline. The REST API 
allows the controller to ignore the `Exec` value for the most part, but the 
current implementation has parallel types `WhiskActionMetadata` and 
`ExecMetadata` to explicitly drop the `Exec` values.
   There is a lot of redundancy in the code - and the two types have drifted 
and changes are in one type and not the other. There is at least one bug that 
I'm aware of because of the drift.
   Thanks to @chetanmeh's work, we do have uniform support for attaching "code" 
as separate entities (CouchDB attachments, S3, etc.). The implementation also 
allows for inlined code up to a certain limit. Because of these changes, we can 
drop the parallel types and improve the CRUD API's performance.
   1. a GET of an action via the REST api today returns a butchered `exec` 
field with no code... is it OK to actually return the internal representation 
of the "code" attachment or do we continue to hide it?
   1. is it ok to cache inlined code (since they are soft references and can be 
gced from the cache)?
   1. all runtimes should be using attachments in the runtimes manifest, and so 
we should remove the property for "attachment" from the runtimes manifest
   1. action operations continue to fetch the attachment and inline it (... 
only to discard it later for the "metadata" classes), this is unnecessary 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

Reply via email to