Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    David de Boer
    @ddeboer
    True. I mean setOptions = pass options when sending the req.
    Márk Sági-Kazár
    @sagikazarmark
    An options argument is easier, with configurable message we don't have to mess with extra interface, etc
    David de Boer
    @ddeboer
    Yes, so just add the optional $options to the HttpAdapter interface?
    As argument to sendRequest(s).
    Márk Sági-Kazár
    @sagikazarmark
    That's an option
    David de Boer
    @ddeboer
    Only 4 days old. Not sure how serious we need to take it. ;)
    Márk Sági-Kazár
    @sagikazarmark
    I have and I am not completely satisfied with it
    This approach is more straightforward
    @param array $options - Vendor-specific options, don't rely on for interop.
    For example that is not possible if you really want to be able to exchange adapters
    Also the factory interfaces are weird IMHO
    and I am not sure why it is a middleware actually
    David de Boer
    @ddeboer
    Yeah.
    Márk Sági-Kazár
    @sagikazarmark
    Anyway, gotta go
    David de Boer
    @ddeboer
    See you!
    Márk Sági-Kazár
    @sagikazarmark
    Will be available in the evening
    Bye
    Márk Sági-Kazár
    @sagikazarmark
    @ddeboer I scheduled 0.1 release for Wednesday evening
    If you have anything to add for the first release (and the guzzle6 adapter, which I modified a little), go ahead ;)
    Márk Sági-Kazár
    @sagikazarmark
    @ddeboer all PRs are merged ;)
    David de Boer
    @ddeboer
    Cool!
    David de Boer
    @ddeboer
    Yeah 0.1.0 is out!
    Márk Sági-Kazár
    @sagikazarmark
    It is
    David de Boer
    @ddeboer
    Have you thought about how to send cookies with requests using the adapters? I guess they should go in $options? As an object or just a simple key/value array?
    Márk Sági-Kazár
    @sagikazarmark
    AFAIK there is some cookie support in ivory http adapter
    David de Boer
    @ddeboer
    Should we have a look at that first?
    Márk Sági-Kazár
    @sagikazarmark
    if there is, it will certainly be migrated at some point
    David de Boer
    @ddeboer
    I say we shouldn’t be too scared to break stuff, though. ;)
    Márk Sági-Kazár
    @sagikazarmark
    Break stuff?
    David de Boer
    @ddeboer
    Well I mean to implement it in a new way and break the old one.
    Márk Sági-Kazár
    @sagikazarmark
    Why should we need to break anything to implement cookies? I agree anyway
    David de Boer
    @ddeboer
    Okay, but there’s currently no event support in the adapters, right? So this subscriber would rather apply to the adapter client.
    Márk Sági-Kazár
    @sagikazarmark
    There will be event support
    David de Boer
    @ddeboer
    But setting the cookies Guzzle 5/6 style should happen in the adapters.
    Márk Sági-Kazár
    @sagikazarmark
    I think it should work as an adapter decorator
    David de Boer
    @ddeboer
    Interesting, how exactly?
    Márk Sági-Kazár
    @sagikazarmark
    similarly to the current implementation in ivory
    there will be support for both symfony and league event dispatchers
    David de Boer
    @ddeboer
    Right.
    Márk Sági-Kazár
    @sagikazarmark
    I think a subscriber method would be more general than allowing cookies in options
    David de Boer
    @ddeboer
    But still the adapters themselves are responsible for setting the cookies in a client-specific way.
    (e.g., G5 allows a plain array, G6 requires a CookieJar etc.)
    Márk Sági-Kazár
    @sagikazarmark
    Right
    Not completely sure how that worked with subscribers
    David de Boer
    @ddeboer
    No, trying to figure that out. I’d say that just passing cooking into sendRequest(…, $options) is necessary anyway.
    Márk Sági-Kazár
    @sagikazarmark
    But if it is possible, I think one general solution is better