search

php-http / utils

[DEPRECATED] HTTP Client Utilities
http://httplug.io
MIT License
2 stars 8 forks source link

User and implementor stuff separation #13

Closed dbu closed 8 years ago

dbu commented 9 years ago

We discussed the role of php-http/utils versus php-http/helper. One idea was to separate things that HTTP client users would need versus HTTP client providers.

BatchRequest and BatchResponse are only relevant for implementors, not for users of a client. The users have to use the BatchResponse interface, and the BatchRequest trait is only relevant for adapters for non-parallel clients. Imho we should move those to helper (and maybe think of a better name for that repository, like client-implementation-helper)

sagikazarmark commented 9 years ago

Yeah, probably this point of view makes the most sense. Even if the logic of package organization might not be clear for everyone at first, it is easy to understand, so let's follow this.

Client-helper maybe?

joelwurtz commented 9 years ago

More than implementation-helper or integration-helper (like the adapter-integration-test package name)

(Client helper is confusing IMO)

joelwurtz commented 9 years ago

It can be closed i think, as all classes here now are user utilities.

dbu commented 9 years ago

right, thanks!

sagikazarmark commented 8 years ago

Reopening this as I think there is room for some more separation here. PR is on the way, after that we can decide about any further separation.

dbu commented 8 years ago

i think the Batch stuff we talked about is now fine here in utils, as there is no more interface. but if there are other implementor-only things i agree to separate them.

sagikazarmark commented 8 years ago

Yeah, that's why I changed the title.

I think that partly the Fulfilled/Rejected Promise thing can also be partly implementor things, but I am in the middle of planning.

In the meantime: naming question is still open. Utils? How should we call the two packages?

dbu commented 8 years ago

i think utils is a good name for user utilities. the other could be implementor-tools maybe?

sagikazarmark commented 8 years ago

From the purpose of point of view, it is a good name.

From a domain point of view, it is not really.

sagikazarmark commented 8 years ago

Pushed changes in the implementation_separation branch.

I would use these tools for example in the guzzle6 adapter where the sync behavior is currently emulated.

dbu commented 8 years ago

From the purpose of point of view, it is a good name.

From a domain point of view, it is not really.

which one? utils? i would stick with utils as purpose is more relevant here than domain - its a collection of stuff really...

for the implementor tools, i am open for better ideas, just tried to come up with a name :-)

sagikazarmark commented 8 years ago

which one? utils?

It is ok.

for the implementor tools

Yeah, this one. I would drop the implementor part if possible. tools? httplug-tools? client-tools? integration-tools as @joelwurtz suggested?

I don't think we will find a name which describes the package correctly, so we definitely need to describe it anyway.

dbu commented 8 years ago

client-tools seems not bad. it goes well with the virtual client-implementation package

sagikazarmark commented 8 years ago

Solved in #20