Skip to content
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

Merged
merged 24 commits into from
Aug 9, 2019
Merged

Conversation

goaway
Copy link
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
library/common/include/c_types.h Outdated Show resolved Hide resolved
library/common/include/c_types.h Outdated Show resolved Hide resolved
library/swift/src/Client.swift Outdated Show resolved Hide resolved
library/objective-c/EnvoyTypes.h Outdated Show resolved Hide resolved
library/objective-c/EnvoyTypes.h Outdated Show resolved Hide resolved
library/objective-c/EnvoyEngine.mm Outdated Show resolved Hide resolved
library/objective-c/EnvoyEngine.mm Outdated Show resolved Hide resolved
library/objective-c/EnvoyEngine.mm Outdated Show resolved Hide resolved
library/objective-c/EnvoyEngine.mm Outdated Show resolved Hide resolved
library/objective-c/EnvoyEngine.mm Outdated Show resolved Hide resolved
rebello95
rebello95 previously approved these changes Aug 3, 2019
Copy link
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.

library/common/include/c_types.h Outdated Show resolved Hide resolved
library/objective-c/EnvoyHttpStream.h Outdated Show resolved Hide resolved
library/objective-c/EnvoyHttpStream.h Outdated Show resolved Hide resolved
library/objective-c/BUILD Outdated Show resolved Hide resolved
if (atomic_load(c->canceled)) {
return;
}
});
Copy link
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
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).

@@ -91,6 +98,9 @@ typedef struct {
*/
@property (nonatomic, strong) void (^onError)(EnvoyEngineError *error);

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

Copy link
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
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.

library/swift/src/Client.swift Outdated Show resolved Hide resolved
library/objective-c/BUILD Outdated Show resolved Hide resolved

/// 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
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
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
Contributor

Choose a reason for hiding this comment

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

Sounds good

@@ -1,7 +1,7 @@
import Foundation

@objcMembers
public final class Envoy: NSObject {
public final class Envoy<Engine: EnvoyEngine>: NSObject {
Copy link
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
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
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
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
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
library/objective-c/BUILD Outdated Show resolved Hide resolved
@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
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>
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>
@rebello95
Copy link
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
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
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