lanthaler
Add support for HTTP libraries (support PSR-7)
Currently file_get_contents is used to retrieve remote contexts and documents. This isn't really flexible and should sooner or later be replaced with a more sophisticated library.
Keep an eye on the PHP FIG Proposal for a HTTP Client interface.
To achieve this maybe http://httplug.io/ would be a good choice. As I understand the the docs an own client implementation is no longer necessary. Meaning a separate class CurlLoad like you mentioned in https://github.com/lanthaler/JsonLD/pull/68 is also unnecessary but a HTTPlug client-implementation will do this through composers require. Is this the way you want to go?
Indeed, HTTPlug looks very promising. There seem to exist adapters for Guzzle and cURL but not file_get_contents (which often is the only thing that works on cheap, shared hosting). Too bad the PHP-FIG couldn’t agree on a client interface yet… but given how simple HTTPlug’s HttpClient interface is, I think this is the way to go for now. Do you have some time to work on this?
I'm on holiday for two weeks now. After this I will look into it, if you have no other schedule. I'm just wonder why they say file_get_content is not important https://github.com/php-http/httplug/issues/32
Hey there,
HTTPlug developer here.
The fact that we marked it as not important doesn't mean you can't have an adapter for file_get_contents. We believe that it is not something which we can easily support and didn't really want to spend time with it. That said, if you would like to work on one, we will happily provide support if necessary.
Thanks for considering using HTTPlug.
Carsten, I doubt I’ll get to it before you. Would really appreciate if you could spend some cycles on it.
Thanks Márk for weighting in here. If we end up creating a file_get_contents adapter, where should it live? In one of our repos or directly under php-http?
@lanthaler it's up to you: if you want to contribute it to php-http, I can't see a reason why we couldn't host it, but it is not necessary to make it work. I guess we can add it to a third-party list if you decide to host it yourself.
OK, as it was raining, I had a couple of hours.. the result can be found at https://github.com/lanthaler/fgc-client :-)
The JsonLD library still needs to be refactored to use this. I have already started updating ml/iri to be PSR-7 conformant (https://github.com/lanthaler/IRI/tree/psr7)
You might also be interested in providing an UriFactory along with your IRI implementation.
Hmm… what depends on it? If it doesn’t provide a clear advantage, I would like to avoid adding a dependency on php-http/message-factory to ml/iri
The advantage: your package will work with HTTPlug out of the box. By adding additional Puli configuration, even the discovery layer will find your implementation and return the UriFactory to the user when an UriFactory is requested.
(You can imagine it as a universal dependency injection module which will just work anywhere)
Understood. My question was what in HTTPlug depends on UriFactory. At the moment nothing seems to depend on it and thus I find it hard to justify pulling in an additional dependency.
I understand the reasons, I think this is the same reason why Guzzle rejected to do so.
However, this way your library (and guzzle psr7) are not really interoperable, or at least not switchable. There is no way to make a library using this package implementation independent, since the construction logic is unique for each implementation (unless you provide something which standardizes construction logic: factory).
I think this is enough justification (and given the fact that you already rely on another contract (psr7), I don't think adding another interface package is a problem).
This is my opinion of course. No hard feelings if you disagree. :smile:
The first step should be to support injection of the loader interface (https://github.com/lanthaler/JsonLD/pull/72) And then it is already possible to substitute any convenient interface implementation (FileGetContentsLoader, CurlLoader, HttpPugLoader, Guzzle6Loader, etc.)
Not sure if I understand: you want another abstraction layer above httplug?
I want to be able to inject right now any other loader implementation instead of FileGetContentsLoader. Maybe later it will be HTTPlug, maybe. But the most important thing is that now i can not use anything other than the built-in FileGetContentsLoader.
I've hacked together a proof-of-concept for a PSR-7 / PSR-17 / PSR-18 loader: https://github.com/tomgillett/JsonLD/commit/df1cff3b610a243cbba25988b25787e287a6b295
Following on from conversation in https://github.com/lanthaler/JsonLD/pull/100
Absolutely. I started moving this into https://github.com/lanthaler/fgc-client a few years ago before those PSRs existed and used HTTPlug instead. If you are interested, we should update that package and then have JsonLD have depend on it and allow people to use other clients. The reason I like file_get_contents is that it supports both local and remote files and is available basically everywhere incl. the cheapest shared hosts.
I'd be happy to contribute some time to this. To explain what I'm looking to achieve...
I'm using this library within an application which integrates with several services via HTTP. If libraries support PSR-18 I can have my application provide a consistent client for all outbound HTTP requests. To me, this is better for maintenance and security and means I can add global configuration to that client if required (i.e. for an outbound proxy, for caching or for logging, etc.)
The alternative is an inconsisent mess - some libraries use file_get_contents, others cURL, others Guzzle - and I have little control over outbound traffic from my application.
I can achieve this now by writing my own implementation of ML\JsonLD\DocumentLoaderInterface (see proof of concept here: https://github.com/tomgillett/JsonLD/commit/df1cff3b610a243cbba25988b25787e287a6b295) but native PSR-18 support feels cleaner to me.