Skip to content

Add native-platform callback implementation#316

Merged
goaway merged 24 commits intomasterfrom
ms-junr03/callbacks
Aug 9, 2019
Merged

Add native-platform callback implementation#316
goaway merged 24 commits intomasterfrom
ms-junr03/callbacks

Conversation

@goaway
Copy link
Copy Markdown
Contributor

@goaway goaway commented Aug 1, 2019

Signed-off-by: Mike Schore mike.schore@gmail.com

@goaway goaway changed the title wip [wip] Add native-platform callback implementation Aug 1, 2019
rebello95
rebello95 previously approved these changes Aug 3, 2019
Copy link
Copy Markdown
Contributor

@rebello95 rebello95 left a 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;
}
});
Copy link
Copy Markdown
Contributor

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?

Copy link
Copy Markdown
Contributor Author

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).


// FIXME
@property (nonatomic, strong) void (^onCancel)();

Copy link
Copy Markdown
Contributor

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?

Copy link
Copy Markdown
Contributor Author

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;
Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
Contributor Author

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good


@objcMembers
public final class Envoy: NSObject {
public final class Envoy<Engine: EnvoyEngine>: NSObject {
Copy link
Copy Markdown
Contributor

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)

Copy link
Copy Markdown
Contributor Author

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.

Copy link
Copy Markdown
Contributor Author

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.

Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
Contributor Author

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(?)

@goaway goaway marked this pull request as ready for review August 5, 2019 22:05
@goaway goaway changed the title [wip] Add native-platform callback implementation Add native-platform callback implementation Aug 5, 2019
rebello95
rebello95 previously approved these changes Aug 5, 2019
@goaway goaway force-pushed the ms-junr03/callbacks branch 2 times, most recently from 615a3be to c17fcc1 Compare August 5, 2019 23:31
rebello95
rebello95 previously approved these changes Aug 5, 2019
Copy link
Copy Markdown
Contributor

@rebello95 rebello95 left a 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.

goaway and others added 11 commits August 5, 2019 17:36
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
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>
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>
@goaway goaway force-pushed the ms-junr03/callbacks branch from c17fcc1 to cbd65cd Compare August 6, 2019 00:36
goaway added 3 commits August 6, 2019 09:46
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>
goaway added 3 commits August 7, 2019 11:12
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>
goaway added 6 commits August 7, 2019 15:34
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>
@rebello95
Copy link
Copy Markdown
Contributor

looks like there's a lint failure on CI but green otherwise!

Signed-off-by: Mike Schore <mike.schore@gmail.com>
@goaway
Copy link
Copy Markdown
Contributor Author

goaway commented Aug 9, 2019

pushed lint fix.

swift library tests all pass locally for me, so I think this is effectively green.

@rebello95
Copy link
Copy Markdown
Contributor

I'm fine with going ahead and merging

@goaway goaway merged commit da4d4d6 into master Aug 9, 2019
rebello95 added a commit that referenced this pull request Aug 12, 2019
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>
rebello95 added a commit that referenced this pull request Aug 13, 2019
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>
@junr03 junr03 deleted the ms-junr03/callbacks branch August 20, 2019 20:47
jpsim pushed a commit to envoyproxy/envoy that referenced this pull request Nov 28, 2022
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>
jpsim pushed a commit to envoyproxy/envoy that referenced this pull request Nov 29, 2022
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants