# |
Mar 2nd 2018, 14:58 |
inoas |
:( |
# |
Mar 2nd 2018, 14:58 |
inoas |
and I don't want things to error out |
# |
Mar 2nd 2018, 14:58 |
inoas |
all those is because some web services are flanky and don't have 100% uptime but are required for front end / end user processes |
# |
Mar 2nd 2018, 14:57 |
admad |
"Custom caching decision" is probably what you would need |
# |
Mar 2nd 2018, 14:57 |
inoas |
though I need it for POST/PUT too... as weird as it sounds - in that case the cached responses would get "consumed" |
# |
Mar 2nd 2018, 14:57 |
inoas |
nice |
# |
Mar 2nd 2018, 14:56 |
admad |
this would be one of the cases where using the beast guzzle would be justified http://guzzle3.readthedocs.io/plugins/cache-plugin.html |
# |
Mar 2nd 2018, 14:50 |
hmic |
lets go for it! i do like your proposal in some weird ways, to allow caching on that level |
# |
Mar 2nd 2018, 14:48 |
hmic |
does not look too bad to me... but once there are more than one adapter, defining an interface does make sense nether the less... |
# |
Mar 2nd 2018, 14:47 |
hmic |
thats a hell of an interface to go wrong :P |
# |
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 |