| # |
Mar 2nd 2018, 14:47 |
inoas |
you got a point there |
| # |
Mar 2nd 2018, 14:46 |
hmic |
inoas, you are really concerned about the 3 methods the adapter exposes? :O |
| # |
Mar 2nd 2018, 14:45 |
inoas |
(same interface for Cake\Http\Client\Adapter\Stream and for my new adapter obviously) |
| # |
Mar 2nd 2018, 14:44 |
inoas |
... and once the interface is build and the adapter runs I should PR that interface to the core? |
| # |
Mar 2nd 2018, 14:44 |
inoas |
hmic the problem is that I also want to prefetch things and store them, just using an outside http proxy is not easier |
| # |
Mar 2nd 2018, 14:43 |
inoas |
so I should build my own interface based on the implicit one |
| # |
Mar 2nd 2018, 14:43 |
hmic |
i still guess it's not worth it... |
| # |
Mar 2nd 2018, 14:43 |
inoas |
ok |
| # |
Mar 2nd 2018, 14:43 |
 admad |
*build |
| # |
Mar 2nd 2018, 14:43 |
admad |
we can discuss adding an interface once you have built your own adapter :slightly_smiling_face: until now no one seems to be interested in spending time doing do |
| # |
Mar 2nd 2018, 14:42 |
inoas |
if you change the internals and there is no interface, things will just crash randomly? |
| # |
Mar 2nd 2018, 14:42 |
hmic |
it seems quite difficult - and bad naming from the start in psr-7, there is so much confusion about request/response in eighter generating or consuming them and the (obviously) differing interfaces and implementations |
| # |
Mar 2nd 2018, 14:42 |
inoas |
how would I know what methods to support now/in future? |
| # |
Mar 2nd 2018, 14:41 |
inoas |
admad ok when the cakephp client adapter is configurable, is there a good reason the only build-in adapter has no interface? |
| # |
Mar 2nd 2018, 14:41 |
hmic |
as the name suggests - it's an adapter (only) |
| # |
Mar 2nd 2018, 14:41 |
inoas |
and for other web services a bunch of requests can be made and the responses can be consumed later |
| # |
Mar 2nd 2018, 14:41 |
inoas |
the idea would be that for some web services data/responses can be cached in case the web services are down and the cache can be rebuild non-blocking |
| # |
Mar 2nd 2018, 14:41 |
admad |
because that interface is for building your own response stream, not consuming an external one |
| # |
Mar 2nd 2018, 14:39 |
inoas |
huh? hinted I know that that's the solution but I wonder why it it not https://github.com/php-fig/http-message/blob/master/src/StreamInterface.php an what interface I should program against |
| # |
Mar 2nd 2018, 14:39 |
hmic |
;) |
| # |
Mar 2nd 2018, 14:39 |
hmic |
i guess he hinted you on the solution with the last sentence |
| # |
Mar 2nd 2018, 14:39 |
inoas |
defaulting to a new adapater is a piece of cake already |
| # |
Mar 2nd 2018, 14:38 |
inoas |
admad so there I am and I was wondering why Http\Client\Adapter\Stream had no Interface |
| # |
Mar 2nd 2018, 14:38 |
hmic |
;-) |
| # |
Mar 2nd 2018, 14:38 |
admad |
then good luck extending and overriding required parts of Http\Client\Adapter\Stream and tell Http\Client to use that class using 'adapter' config |
| # |
Mar 2nd 2018, 14:38 |
hmic |
however, you need to recreate a response object from stored data in this case. which is, like admad said, non-trivial at best |
| # |
Mar 2nd 2018, 14:37 |
hmic |
what about directing your requests to a caching proxy to hide the complexity from the app *completely*? :P |
| # |
Mar 2nd 2018, 14:36 |
inoas |
some caches should be consumable - configure thing |
| # |
Mar 2nd 2018, 14:36 |
inoas |
so I can drop it in and it will behave based on a little bit of configuration exactly like Client ... or return things from cache depending on the same url/query-string/http-headers and cache-time-window |
| # |
Mar 2nd 2018, 14:35 |
inoas |
I want to basically change the class from Client to CachedClient and have maybe a few Configure::readOrFail() settings and then when a request comes in it either goes through or returns things from cache |
| # |
Mar 2nd 2018, 14:34 |
inoas |
admad but what I want to do is hide complexity from the app |
| # |
Mar 2nd 2018, 14:33 |
admad |
or maybe use something like this https://github.com/micheh/psr7-cache |
| # |
Mar 2nd 2018, 14:32 |
admad |
don't try to add caching directly in http client, it's non trivial. Just get the response string as i showed and cache. Then use whatever app logic you need to decide whether to make a new request or just used the cached response string |
| # |
Mar 2nd 2018, 14:31 |
hmic |
you will need to build up the response object from the cached data again, sure. you can't just store/serialize the object with all the state |
| # |
Mar 2nd 2018, 14:30 |
inoas |
I had problems with the adapter being a stream one |
| # |
Mar 2nd 2018, 14:30 |
inoas |
:( |
| # |
Mar 2nd 2018, 14:30 |
inoas |
I will try again |
| # |
Mar 2nd 2018, 14:30 |
inoas |
and for a cached response you would get back all the response code, response headers etc |
| # |
Mar 2nd 2018, 14:30 |
hmic |
inoas, so create a response in your class and feed the data you've got? whats the point? |
| # |
Mar 2nd 2018, 14:29 |
hmic |
thats about what i would have thought about the client too. who cares about the inner implementation, you get the body back anyways |
| # |
Mar 2nd 2018, 14:29 |
inoas |
much like $response = (new CachedClient)->get($url); |