Plugins planned #3
Comments
|
Are you okay with me implementing the Tape Recorder part :)? Unless someone else is already at it, of course! |
|
No problem go ahead :) |
|
@jeromegamez it's good to see you here. 😄 No problem at all, it is your baby anyway. I was looking at VCR. Do you think there is a possibility to join forces with them? Honestly, I never used these tools too much, just played with them. However, if they are the same, why couldn't we team up with them? I don't insist on it, I leave this to you, but it would be good to investigate what the possibilities are. |
|
What's the difference between history and logger? |
|
@jeromegamez awesome! i created #4 to discuss this in its own thread. |
Logger log request / response / exception to a psr/log implementation The real distinction comes from the "couple" thing, in logger plugin there a just some events which may or may be not related, in history the trace is always with the couple |
|
I see. Where is history data kept? |
|
The default implementation from ivory http adapter kept data in memory (with a variable), see https://github.com/egeloen/ivory-http-adapter/blob/master/src/Event/History/Journal.php |
|
so the history one would be a meta plugin for other tools (like a symfony toolbar integration) to extract what happened during this request? |
Like a data collector thing yes |
|
That sounds good. @dbu can it somehow be added to the HttplugBundle? |
|
yes, HttplugBundle would be the right place for integrating the history
plugin with the symfony toolbar
|
|
Updated the list : Compression and Chunk should be in one plugin (Encoding) |
|
Cache is something that is experimental even in guzzle, would be nice to have. Not sure though whether we need cache if we have VCR or not. |
|
I think they all depend on a mutual dependancy like the Formatter / Normalizer thing (which can also be used in the Log plugin), so we can serialize a http request in another format. But despite from that workflow and usage is not the same. |
|
cache sounds like a great idea. and while vcr is similar, its not the
same. cache should likely respect the cache header instructions. vcr
should unconditionally cache.
|
|
VCR even doesn't cache. In VCR's domain, I'm asking you: what is a cache? Has this something to do with those hipster people strolling through the woods searching for treasures? I just know cassettes, racks and my recorder 😇 |
|
But seriously, I also think that the VCR shouldn't be more than that: the notion of a TTL would already be oit of scope. |
|
absolutely. however, the mechanics of restoring a response matching some
request from a file is the same as a cache. there might be potential to
share code.
|
|
@jeromegamez you probably spent more time with this than me, so I guess you know better, it was just an idea. However this raises a question: VCR has a storage layer, doesn't it? I agree, that caching is something else. |
|
Plugins repo is probably on the right way. I think we should not finish all the plugins prior to the stable release. Partly because some components (like caching and formatter) require more planning/duscussion, partly because I don't want to hurry just because stable release, partly because we have other work to do: polishing discovery, message factory, documentation, not to mention the packages used by plugins (authentication, cookie). We probably have enough plugins implemented for the stable release. There are a few "would be nice to have"s, like Base URI, Sanitizer, Encoding, but I think none of them is requirement. This repo should also be reviewed. I've already found minor CS errors, I will provide a PR for those. @joelwurtz @dbu what's the situation with plugin docs? Have anybody written any docs? |
|
agree that we should not wait for having lots of plugins implemented for
a 1.0. but we need to see the architectural approach works.
regarding docs: there is only the reminder issue
php-http/documentation#15 . joel, can you
write some documentation for that and i review that? once we have the
general stuff and the already existing plugins documented, it should
also be easier to add doc about each plugin as we add it to the system.
|
|
Will try to begin some documentation on this tomorrow will do that directly on a branch so you can edit yourself |
|
Ok to remove the Timer / Formatter Plugin, they were not plugin in ivory http adapter, just class to add information on the Logger / Journal Plugin ? |
|
sounds right.
|
|
I think with the two plugins already in PR, next work will be on the BaseUri plugin and History plugin, after that we can safely release a first / alpha version of plugin-client (BaseUri is the most needed one i think) |
|
Agree. I would concentrate on BaseURI and cleaning up/proofreading existing code. History plugin can wait I think. |
|
does a base uri plugin make sense? i thought we discussed that its not
possible to create messages without a valid uri? or was this plugin
about synchronizing domain in uri and HOST header?
|
|
Hm, I remember something about this discussion, but I can't recall where we discussed it. Also, host is only required for 1.1 |
Absolutely, but shouldn't it be an authentication component instead? https://github.com/php-http/authentication
I would turn it upside down. Since you actually need the iterator, not the client itself, I would use Pagerfanta with a custom adapter. Although I don't think such a plugin/adapter is easy: you need insights about the content, it's format, etc which doesn't seem to be a responsibility of the HTTP part of your code. |
Yes, I think, it's better to make it inside
You're right, will think about additional utility for this. |
|
@RomeroMsk There’s now Bearer support in php-http/message. Is that sufficient for your needs? |
|
@ddeboer, not it's not enough. Adding the bearer header to request is not a big problem. We need to fetch the token from auth endpoint first and refetch it in case of 401 HTTP Status. |
How you fetch and refresh a token is very specific to the API. I think it is hard to try to standardize in a http client/plugin. |
No, OAuth v2 - is standard. Token is fetching by HTTP request with strictly defined parameters. So it can be standardized in plugin. |
|
You’re right, @RomeroMsk, the standard OAuth2 flows should be done inside a plugin. Do you have time to work on an OAuth2 plugin? |
|
Yes, OAuth v2 is standard. But the implementation of it differ.
|
|
Right, these are (mostly) different implementations of the same RFC 6749 standard.
|
|
We could have a look at https://github.com/commerceguys/guzzle-oauth2-plugin for inspiration. |
Sorry, have no time to work on it now.
Or at this: https://github.com/thephpleague/oauth2-client |
|
Agreed on integration with the phpleague component, as that’s the direction commerceguys seems to take as well. @sagikazarmark Do we need a separate plugin or only a php-http/message Authentication component? |
|
Hard question, which I am trying to answer for some time. I think the problem is that we can't authenticate and send the original request in one request, which means we need to start at least one new request, which means we need a separate plugin for this. Another solution would be some kind of Authentication interface which allows doing some extra logic apart from authenticating the request itself. About league oauth: it looks promising. It would allow us to implement an Authentication method in a nice way. However it uses guzzle 6 internally, which itself is not a problem, but then (at least for now) Guzzle 6 would be a requirement to use our OAuth authentication method. We could probably ask them if they want to use httplug in the future. |
True, but the request would be sent by thephpleague/oauth2-client, so either through Guzzle 6 (currently) or later through HTTPlug. As long as our plugin acts on the correct headers (so doesn’t act on OAuth authentication requests), we’re good. Is the separate oauth2-client dependency a reason to put the OAuth2 plugin in a separate repo or do we already have plugins with optional (yuck) dependencies? |
|
OK, let's do this. Having it as an authentication method is nicer than having a separate plugin for it. |
|
Ok, so add it to php-http/message and see how far we get? |
|
Yup. Do we need at least an authorization code in advance? In most cases we can't confirm access on an authorization page, can we? |
|
I think oauth2 will be better integrated with an Oauth2Client implementing HttpClient / HttpAsyncClient and decorating an HttpClient / HttpAsyncClient with the PluginClient for the AuthenticationPlugin WDYT ? |
|
Why? I think with the plugin system we wanted to avoid such decorations whenever possible. Also, if we plan to use league oauth, a client wrapper seems to be an overkill. |
|
Because Oauth2 is not something which change the request / workflow behavior and is more a standard around http. It will do multiple calls and i find it cleaner as a decorator than a plugin. |
This is not true, it changes the requests (adds the token).
That's true, but this is why there is a
What about this one? |
|
lets try to build that plugin and see if it feels iffy. and talk to the league maintainers of oauth to see if they can be interested in httplug. |
You mean authentication method? |
|
sorry, got confused by the issue title and all. yes, authentication method. |
|
Closing this, as i think Sanitizer plugin is not useful (separated into other plugins, with the ContentLengthPlugin as an example) and validator plugin not really a indispensable one, as it does not make sens to have this at runtime IMO |
|
Regarding the TapeRecorder plugin (PHP-VCR alike), I did an implementation some time ago. The public API is a big wacky and it need some documentation, but, here you go : https://github.com/eleven-labs/http-replay-plugin |
plugins planned (new or migrate from Ivory):
The text was updated successfully, but these errors were encountered: