Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce behaviours #91

Closed
sagikazarmark opened this issue Jul 18, 2016 · 6 comments
Closed

Introduce behaviours #91

sagikazarmark opened this issue Jul 18, 2016 · 6 comments

Comments

@sagikazarmark
Copy link
Member

Q A
Bug? no
New Feature? yes

At the moment we support flexible client and methods client via options of the client definition with simple flags set to true. However this makes it harder to nest these client behaviors (even if it might not make too much sense at the moment). Instead of these flags, I propose the following:

httplug:
    client:
        acme:
            factory: 'acme_client_factory'
            behaviors:
                - flexible
                - something_else
                - batch

This would allow to nest multiple behavioral clients into each other. Of course we have to take care of type safety (behavioral clients might be sync or async clients (or both), but we need to check that before each nesting to see what the next behavior supports)

This would also ensure futureproof flexibility.

@sagikazarmark sagikazarmark modified the milestone: v1.3.0 Jul 18, 2016
@dbu
Copy link
Collaborator

dbu commented Jul 19, 2016

interesting idea. i am not exactly sure of the use case, but it could be
useful.

but if we nest those clients, one would need a way to access both the
methods and the batch behaviour, but if its layers of decorators, that
is not possible. we would need traits and all permutations of combined
clients, no?

@sagikazarmark
Copy link
Member Author

i am not exactly sure of the use case, but it could be useful.

Example use case: you have a sync client which you wrap in a flexible client, then wrap it in a batch client. I know this is kind of an edge case, but this is a case that we have at the moment. However, the current approach is not flexible enough to support any future use cases.

but if we nest those clients, one would need a way to access both the methods and the batch behaviour

No, I don't think so. It's the responsibility of the user to now what behaviours are nested into each other. For example I can imagine two or three nested decorators end up in a batch client in the end. During the nesting we need to check in each case if the specific nest is supported (eg. the returned client from the previous nesting needs to be an HttpClient) and throw an error when an illegal nesting happens.

@dbu
Copy link
Collaborator

dbu commented Jul 19, 2016 via email

@sagikazarmark
Copy link
Member Author

Yeah, this idea was born on the suburban train in a pre-coffee state, so definitely needs some more thinking, examples, etc.

@fbourigault
Copy link
Contributor

Small note, as clients created through the config are all PluginClient, there are all flexible.

@ostrolucky
Copy link
Collaborator

Let's close, this didn't gain much traction

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants