Skip to content

Discovery bugfixes and more flexible. #87

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

Merged
merged 9 commits into from
Jul 18, 2016
Merged

Conversation

Nyholm
Copy link
Member

@Nyholm Nyholm commented Jul 16, 2016

Q A
Bug fix? yes
New feature? yes
BC breaks? no
Deprecations? no
Related tickets
Documentation
License MIT

What's in this PR?

With this PR I wanted to achieve two things:

  • A way to configure which client that should be used with auto discovery
  • A way to opt-out of providing a auto discovery client in the toolbar.

@Nyholm Nyholm changed the title Dev conf discovery Discovery bugfixes and more flexible. Jul 16, 2016
@sagikazarmark sagikazarmark changed the title Discovery bugfixes and more flexible. Discovery bugfixes and more flexible. Jul 16, 2016
@sagikazarmark sagikazarmark modified the milestone: v1.2.0 Jul 16, 2016
@@ -83,6 +83,8 @@ public function getConfigTreeBuilder()
->defaultValue('auto')
->end()
->scalarNode('formatter')->defaultNull()->end()
->booleanNode('inject_debugger_for_discovered_http_client')->defaultTrue()->end()
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure if we want this opt-in by default.

Copy link
Member Author

Choose a reason for hiding this comment

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

Why not? All the other clients are opt-in by default.

Copy link
Member

Choose a reason for hiding this comment

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

Correct me if I am wrong, but this will register the default client in the discovery, will it not? If so, all the problems I listed in the previous PR can still occur. I would rather have this as an optional feature stating you can turn this on for discovered clients if you want.

Copy link
Member

Choose a reason for hiding this comment

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

Can we find a shorter name? Like profile_discovered_client and profile_discovered_async_client

Copy link
Member Author

Choose a reason for hiding this comment

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

Correct me if I am wrong, but this will register the default client in the discovery, will it not?

No, It will find take a (new) unconfigured client and add toolbar debugging on that and then make sure that this client is found by discovery in the future.

This PR also lets to you decide if you want to use a configured client as auto discovery.

Can we find a shorter name? Like profile_discovered_client and profile_discovered_async_client

Yes please. It was quite late last night when I wrote this. =)

Copy link
Member

Choose a reason for hiding this comment

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

Okay, so by default a discovered, unconfigured client is simply wrapped with debug tools and put back to discovery and you can also choose to use a configured client for that, but that is optional, opt-out by default?

@Nyholm Nyholm force-pushed the dev-conf-discovery branch 2 times, most recently from 201bcb6 to d5e9bcd Compare July 18, 2016 06:47
@dbu
Copy link
Collaborator

dbu commented Jul 18, 2016

you might need to cherry-pick commits into a new branch as #84 is now squashed. there is a conflict reported by github.

@Nyholm
Copy link
Member Author

Nyholm commented Jul 18, 2016

Yes. I'll make this PR ready for review shortly.

@Nyholm Nyholm force-pushed the dev-conf-discovery branch 2 times, most recently from d0f9be9 to c380db9 Compare July 18, 2016 08:34
@Nyholm Nyholm force-pushed the dev-conf-discovery branch from c380db9 to d49f7d6 Compare July 18, 2016 08:35
@Nyholm
Copy link
Member Author

Nyholm commented Jul 18, 2016

There. This PR is ready for review.

Consider the following config

httplug:
    toolbar:
      profile_discovered_client: true # Default
      profile_discovered_async_client: false # Default
    classes:
    clients:
        my_guzzle6:
            factory: 'httplug.factory.guzzle6'
        acme:
            factory: 'httplug.factory.curl'

This will create a two new private services: httplug.auto_discovery_client.pure and httplug.auto_discovery_client.plugin. The underlying client is a new client found by auto discovery. Next time a third party library is using auto discovery it will find the httplug.auto_discovery_client.plugin which is configured with debug stuff.

If a user want to control what client is found by auto discovery he/she may add use_with_discovery to the client.

httplug:
    toolbar:
      profile_discovered_client: false # Does not matter when 'use_with_discovery'
      profile_discovered_async_client: false # Default
    classes:
    clients:
        my_guzzle6:
            factory: 'httplug.factory.guzzle6'
        acme:
            factory: 'httplug.factory.curl'
            use_with_discovery: 'http_client'

@sagikazarmark
Copy link
Member

use_with_discovery: 'http_client'

What does this mean? Neither the key nor the value is obvious IMO.

@Nyholm
Copy link
Member Author

Nyholm commented Jul 18, 2016

You can choose what client to be found by HttpClientDiscovery::find and HttpAsyncDiscovery::find.

I added a comment about it here: https://github.com/php-http/HttplugBundle/pull/87/files#diff-850942b3ba24ab03a40aaa81b6152852R129

But maybe that was not the best one

@sagikazarmark
Copy link
Member

What if someone wants one client to be used as both? Is there a type check to make sure the chosen client is actually of the relevant type? What if this is configured for multiple clients?

@Nyholm
Copy link
Member Author

Nyholm commented Jul 18, 2016

What if someone wants one client to be used as both?

Correct. That was missing

Is there a type check to make sure the chosen client is actually of the relevant type?

Yes, In the discovery strategies contstuctor

What if this is configured for multiple clients?

Then an exception will be thrown

@sagikazarmark
Copy link
Member

Then maybe we could have the following configuration:

httplug:
    discovery:
        client: client_id # optional
        async_client: async_client_id # optional
        profile_client: true
        profile_async_client: false

@Nyholm
Copy link
Member Author

Nyholm commented Jul 18, 2016

I like it!
Will do

@Nyholm
Copy link
Member Author

Nyholm commented Jul 18, 2016

Since profile_client as no effect when using httplug.discovery.client I suggest:

httplug:
    discovery:
        client: 'auto' # could also be a service name like 'httplug.client.acme'
        async_client: 'none' # default

But this does not however tell you about the profiling... Is there a better config?

@sagikazarmark
Copy link
Member

When there is a concrete client configured, profiling is enabled for it automatically?

@Nyholm
Copy link
Member Author

Nyholm commented Jul 18, 2016

Yes

@sagikazarmark
Copy link
Member

Then I am fine with that. Although probably we should have null (~) values by default and those should be mapped to auto and none. WDYT?

@Nyholm
Copy link
Member Author

Nyholm commented Jul 18, 2016

This PR is now ready for review

->info('Set to "auto" to see auto discovered client in the web profiler. If provided a service id for a client then this client will be found by auto discovery.')
->end()
->scalarNode('async_client')
->defaultNull()
Copy link
Collaborator

Choose a reason for hiding this comment

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

why not auto as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because if no AsyncClient is found we get an exception. I do not think I can catch that.

Copy link
Collaborator

Choose a reason for hiding this comment

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

okay. but then lets change the info to mention that you should set this to auto if you know that you have an async client available.

Copy link
Member Author

Choose a reason for hiding this comment

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

Or should I put that in the docs?

Copy link
Member Author

Choose a reason for hiding this comment

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

@dbu
Copy link
Collaborator

dbu commented Jul 18, 2016

i have one question and one suggestion. but overall, this looks good, i like it. please also start with the documentation as soon as we are set on how this works, so that we don't forget the details of auto vs null and so on...

@sagikazarmark
Copy link
Member

Can we merge this and tag v1.2?

}

/**
* {@inheritdoc}
*/
public static function getCandidates($type)
{
if (static::$client !== null && $type == HttpClient::class) {
if (static::$client !== null && $type === HttpClient::class) {
Copy link
Member

Choose a reason for hiding this comment

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

Should the type check rather come first? This way the first condition is evaluated even if the type is a MessageFactory.

@sagikazarmark sagikazarmark merged commit 1e806aa into master Jul 18, 2016
@sagikazarmark sagikazarmark deleted the dev-conf-discovery branch July 18, 2016 21:16
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