explore the viability of a simple http client in doctrine common
Closed this issue · 10 comments
just wanted to open this as a ticket. i think it totally makes sense to use Buzz right now. but once all the core pieces are in place, we should review once more if we cannot simple move the CouchDB ODM HTTP client to common along with an interface and potentially a few adaptors for popular http clients.
Sure. The Buzz Client is capsuled by a doctrine-HttpCLientInterface. So we can just replace Buzz by a common doctrine HTTP client. Perhaps we could start with the interfaces we are currently building and add methods which you (and others) think that needs to be added to be a common doctrine interface. Later then we could move it to the common part.
like i said .. imho we can wait until you are closer to having a working and semi finished search API done ..
Why not adopt Buzz if that is okay with Kris ?
i think the scope Doctrine Common isn't to provide an http client that can do it all. But I do think its a good idea to keep the out of the box dependencies as small as possible. So I am sure in the end our HTTP client will not have all the features of Buzz, but will provide a good out of the box experience.
Yes. Then lets start to define the Doctrine HttpClientInterface.
Mike Lohmann
0171 270 4156
Am 11.11.2011 um 08:41 schrieb Lukas Kahwe Smith
reply@reply.github.com:
i think the scope Doctrine Common isn't to provide an http client that can do it all. But I do think its a good idea to keep the out of the box dependencies as small as possible. So I am sure in the end our HTTP client will not have all the features of Buzz, but will provide a good out of the box experience.
Reply to this email directly or view it on GitHub:
#22 (comment)
I'd be happy to write an adapter and tests to integrate Guzzle with the HttpClientInterface.
Hi,
It would be nice to have an other client supporting the client interface.
At a first view the Guzzle-Http-Client brings much functionality we
perhaps don't need. If you want to implement it with the current
interface it can be used but I don't see it as the common http client.
Imho we should find the requirements for a common http-client first.
Then design the interface.
I agree to Lukas and think we should wait a little more, until we have
a basic functionality working. Perhaps we than have a deeper
understanding of what we really need in the client and can define a
interface suits our needs.
What do you think?
2011/11/11 Michael Dowling
reply@reply.github.com:
I'd be happy to write an adapter and tests to integrate Guzzle with the HttpClientInterface.
Reply to this email directly or view it on GitHub:
#22 (comment)
I agree. I think it's a good idea to create an HttpClientInterface for common and provide a simple implementation that covers most use cases. I am saying that if you want adapters for HTTP clients after this interface has been created, then I can create an adapter for Guzzle.
Ah. Cool. :)
2011/11/11 Michael Dowling
reply@reply.github.com:
I agree. I think it's a good idea to create an
HttpClientInterfacefor common and provide a simple implementation that covers most use cases. I am saying that if you want adapters for HTTP clients after this interface has been created, then I can create an adapter for Guzzle.
Reply to this email directly or view it on GitHub:
#22 (comment)
The current elastic search is using elastica. I think this can be closed.