Event Lifecycle Receiver problem

[SeanTAllen]

Imagine we have 3 receivers:

• SSL
• base TCP
• Sean's special

For reading we want it to go:

• base TCP
• SSL (to decrypt)
• Sean's special (to do the special handling)

For writing we want:

• Sean's special
• SSL
• base TCP

This means that for reading we want to call:

SSL then Sean's Special so SSL should wrap Sean's special: We need to decrypt the data before Sean's special can handle it.

For writing we want Sean's special then SSL which means that Sean's special should wrap SSL. We want to encrypt the data after Sean's special has handled it.

We need to be able to have an order for receiver's for reading and for writing that can differ.

At the moment we have a single receiver type. We need to take more than 1. 3 probably:

• Standard
• Reading
• Writing

[SeanTAllen]

The receivers could be all on individual objects but we need a way to order the calling of them.

I think perhaps what we what is to push that onto the programmer setting up the receivers an require them to sequence themselves.

We could do this if I as the programmer must create "my lifecycle receiver" which in turn takes a "SSL receiver" and "Sean's special receiver"

then we have something like

fun ref on_send(data: ByteSeq): (ByteSeq | None) =>
  match seans_special.on_send(data)
  | let d: ByteSeq =>
    return ssl.on_send(d)
  end

  None

fun ref on_received(data: Array[U8] iso): (Array[U8] iso | None) =>
  match ssl.on_received(consume data)
  | let d: Array[U8] iso => 
    match seans_special.on_received(d)
    | let d: ByteSeq =>
      // our own logic
    end
  end

  None

Things could be done to make this nicer but there's no magic. Just setup that any programmer can do and could abstract away if they wanted.

However, better would be not "these are different receivers" but more like:

interface SendInterceptor
  fun ref modify_outgoing(data: ByteSeq): (ByteSeq | None)

interface ReceiveInterceptor
  fun ref modify_incoming(data: Array[U8] iso): (Array[U8] iso | None)

With this, the earlier code would be more like:

fun ref on_send(data: ByteSeq): (ByteSeq | None) =>
  match seans_special.modify_outgoing(data)
  | let d: ByteSeq =>
    return ssl.modify_outgoing(d)
  end

  None

fun ref on_received(data: Array[U8] iso) =>
  match ssl.modify_incoming(consume data)
  | let d: Array[U8] iso => 
    match seans_special.modify_incoming(d)
    | let d: ByteSeq =>
      // our own logic
    end
  end

  None

This adds a great deal of flexibility in return for anyone wanting to use SSL having to hook in at the proper points. So extra work because "no magic", but more ability to craft as you need.

The pain could also be made "easier" when we consider that usually people will want "just SSL" so we can provide a "just SSL" as part of lori and the above sort of sequencing can be done by hand if needed.

[SeanTAllen]

Actually the previous bit is conflating a couple items.

Given:

interface SendInterceptor
  fun ref modify_outgoing(data: ByteSeq): (ByteSeq | None)

interface ReceiveInterceptor
  fun ref modify_incoming(data: Array[U8] iso): (Array[U8] iso | None)

Then really I should be able to do:

class MyInterceptor
  let _ssl: SSLInterceptor
  let _sean: SeanInterceptor

  new create(ssl: SSLInterceptor, sean: SeanInterceptor) =>
    _ssl = ssl
    _sean = sean

  fun ref modify_outgoing(data: ByteSeq): (ByteSeq | None) =>
    match _sean.modify_outgoing(data)
    | let d: ByteSeq =>
      return _ssl.modify_outgoing(d)
    end

  fun ref modify_incoming(data: Array[U8] iso): (Array[U8] iso | None)
    match _ssl.modify_incoming(consume data)
    | let d: Array[U8] iso => 
      return _sean.modify_incoming(d)
    end

    None

Then this "interceptor" is supplied to the TCPConnection as part of its creation as a different item from our lifecycle event handler.

Where we can think of these "interceptors" as more "protocol level" vs the lifecycle event handlers as "application level" and we don't conflate the two concerns.

Application level is written by the "final programmer". Protocol level can be supplied as "library functionality" for usage by "final programmer"