-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add native-platform callback implementation #316
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! Let's ship and iterate on master.
if (atomic_load(c->canceled)) { | ||
return; | ||
} | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be calling back up to the platform?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, some of this is more of a sketch; working headers is the main goal for this PR (with the framework in place to get the rest working).
library/objective-c/EnvoyTypes.h
Outdated
@@ -91,6 +98,9 @@ typedef struct { | |||
*/ | |||
@property (nonatomic, strong) void (^onError)(EnvoyEngineError *error); | |||
|
|||
// FIXME | |||
@property (nonatomic, strong) void (^onCancel)(); | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add one for onComplete
too? Or is the assumption that onTrailers
encompasses this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current plan is not to surface onComplete, since it's actually meant more to trigger internal bookkeeping. Other callbacks have the boolean on them and trailers/error imply closure already.
That said we can surface this if it ends up being necessary/useful. Currently though, it will be a little bit redundant.
|
||
/// Performs necessary setup after Envoy has initialized and started running. | ||
/// TODO: create a post-initialization callback from Envoy to handle this automatically. | ||
+ (void)setupEnvoy; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is defined here, should probably also be in the EnvoyEngine
interface
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kept this here because the plan is to get rid of it as soon as we have the post-init callback wired up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good
library/swift/src/Envoy.swift
Outdated
@@ -1,7 +1,7 @@ | |||
import Foundation | |||
|
|||
@objcMembers | |||
public final class Envoy: NSObject { | |||
public final class Envoy<Engine: EnvoyEngine>: NSObject { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this needs to be generic. @buildbreaker and I were considering just instantiating this class with an EnvoyEngine.Type
(for class methods, or an instance of EnvoyEngine
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't need to be I guess. Are there downsides?
I went this direction because it felt a little cleaner to me than passing the type as an initialization parameter that needs to be stored and referenced, esp. when the interface is static.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it makes more sense in the context that our current thinking is that EnvoyEngine will always be static, and Envoy will be the platform instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generics are harder to pass around in platform code, because everything that uses them also needs to be generic. For example, we'd have to do:
func foo<T: EnvoyEngine>(_ envoy: Envoy<T>)
Instead of:
func foo(_ envoy: Envoy)
Reducing the generic and instead keeping the type hidden within the object will remove the need for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But nothing else should actually need the generic type right? Like foo
doesn't need to know the specialized type of Envoy
. Pretty sure func foo(_ envoy: Envoy)
should still work(?)
615a3be
to
c17fcc1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work getting this set up. Let's merge and iterate.
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
c17fcc1
to
cbd65cd
Compare
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
looks like there's a lint failure on CI but green otherwise! |
pushed lint fix. swift library tests all pass locally for me, so I think this is effectively green. |
I'm fine with going ahead and merging |
This was originally going to be done as part of #316, but we ran into build issues. Making this change will allow us to mock `EnvoyEngine` from the Swift/Kotlin platform layers. Signed-off-by: Michael Rebello <me@michaelrebello.com>
This was originally going to be done as part of #316, but we ran into build issues. Making this change will allow us to mock `EnvoyEngine` from the Swift/Kotlin platform layers. Signed-off-by: Michael Rebello <me@michaelrebello.com>
This was originally going to be done as part of envoyproxy/envoy-mobile#316, but we ran into build issues. Making this change will allow us to mock `EnvoyEngine` from the Swift/Kotlin platform layers. Signed-off-by: Michael Rebello <me@michaelrebello.com> Signed-off-by: JP Simard <jp@jpsim.com>
This was originally going to be done as part of envoyproxy/envoy-mobile#316, but we ran into build issues. Making this change will allow us to mock `EnvoyEngine` from the Swift/Kotlin platform layers. Signed-off-by: Michael Rebello <me@michaelrebello.com> Signed-off-by: JP Simard <jp@jpsim.com>
Signed-off-by: Mike Schore mike.schore@gmail.com