Sorry it took me a while to write this up, but finally here is a draft of what I mean by "typed implementations".
The proposed grammar is actually very simple. Instead of "implementation" having that weird structure of a "primary" string and a string-list of "dependencies", which semantically were never very clear, I suggest that it be given a data type using a "type" keyword for both the operation definition and assignment (a refinement of the definition).
This data type provides syntactical validation for "implementation", but more importantly it represents the processor's mechanism for reacting to the operation event.
In the example below I'm showing a node with two operations. One of them is a gRPC call and the other is remote execution using ssh. Both of them are "remote", and the default for the Remote data type from which they both derive assumes that the node has an "address" attribute. However, this default address can be overridden and given a different value if necessary, for example if the node is not a server itself, or if another component (an orchestrator) is handling execution.
The gRPC call has nothing to do with artifacts per se. However, it is expected that there is a gRPC client somewhere that can handle these calls, perhaps statically compiled from a ".proto" file, which perhaps can be included in the CSAR. But that ".proto" file defines the entire membrane, not individual calls. It's also possible to imagine a ".proto"-to-TOSCA translator that would create derived data types and for each supported call and one big interface type.
The ssh implementation is actually quite similar, but it does have optional support for artifacts. The idea is that the artifacts would be copied over (scp) before executing the ssh command. Here we can extract TOSCA artifacts from the CSAR using the "get_artifact" function or just use any file from a URL. One issue is what to do with inputs: setting environment variables may be impossible (PermitUserEnvironment is set to false for most sshd deployments). So, what I am suggesting here is that the processor would know how to pack the inputs into a command-line-compatible string. The result is something which I think is most similar to the spirit of the existing "primary + dependencies" structure of "implementation", but I did want to present some of the complexities regarding where the command runs and how to construct it.
Also note a simple use of metadata in order to configure specific aspects of execution for specific orchestrators.
This approach raises a more general issue regarding interfaces in TOSCA. In much of our thinking and examples until now we've treated interfaces as a design element coming from TOSCA. In the Simple Profile specifically they represent the lifecycle as defined by TOSCA. So, our job in that case is to then map that paradigm onto whatever exists in the real world. This mapping needs to be done not just in TOSCA but likely also with some kind of adapter layer. In Ubicity this layer is a collection of executable scripts. But I want to suggest that there's another approach in which we actually start from the real world and find ways to expose it to TOSCA. For example above I mention that an existing ".proto" file (or a Swagger schema) can be translated into TOSCA. In this approach the designer actually has no freedom to create arbitrary interfaces, because they are defined by the environment, and there's no adapter layer: it is a direct membrane to the environment. TOSCA's job, then, is to map data from the topology into that given interface. And that's where better topology traversal functions (get_property/get_attribute) would be really useful.
There are a lot of issues I'm not addressing here, but I want to start the discussion simply!
The example:
interface_types:
 Maintenance:
  operations:
   maintenance-on:
    inputs:
     mode:
      type: string
      constraints:
      - valid_values: [ staging, production ]
   maintenance-off:
    type: SSH # data type for the implementation. if not declared, must be set in assignment
    inputs:
     immediate:
      type: bool
data_types:
 Remote:
  properties:
   address:
    type: string
    default: { get_attribute: [ SELF, address ] }
   credentials:
    type: Credentials
    default: { get_input: credentials }
 GRPC:
  derived_from: Remote
  properties:
   rpc:
    type: string
   timeout:
    type: scalar-unit.time
    required: false
   user-agent:
    type: string
    default: TOSCA
 SSH:
  derived_from: Remote
  metadata:
   myorchestrator.executor: fabric
  properties:
   command:
    type: list
    entry_schema: string
   work-dir:
    type: string
    default: /tmp
   files:
    description: Copy over these files (optional)
    type: list
    entry_schema: string
node_types:
 Server:
  interfaces:
   Maintenance:
    type: Maintenance
topology_template:
 node_templates:
  server:
   type: Server
   interfaces:
    Maintenance:
     operations:
      maintenance-on:
       type: GRPC
       implementation:
        rpc: StartMaintenanceWithMode
        timeout: 10 s
       inputs:
        mode: production
      maintenance-off:
       implementation:
        command: [ /usr/bin/bash, -c, '/home/tosca/off.sh $INPUTS > off.log' ]
        files:
        - { get_artifact: [ SELF, main ] }
        - { get_artifact: [ SELF, utils ] }
        - http://acme.org/utils/lib.tar.gz
       inputs:
        # This will be packed as "--immediate=true" in $INPUTS
        immediate: true
   artifacts:
    main:
     file: off.sh
     deploy_path: /home/tosca
    utils:
     file: utils.sh
     deploy_path: /home/tosca