Move this library to php-http organisation?

[Nyholm]

What do you think? Do we want to continue the work of this library together?

Ping @joelwurtz @dbu @sagikazarmark

[sagikazarmark]

Shouldn't we merge it into message?

Tobias Nyholm notifications@github.com ezt írta (2016. július 16.,
szombat):

What do you think? Do we want to continue the work of this library
together?

Ping @joelwurtz https://github.com/joelwurtz @dbu
https://github.com/dbu @sagikazarmark https://github.com/sagikazarmark

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABK2kIbrtyEgB7TfumWs0QKWMq4GG7K8ks5qWLMagaJpZM4JN_Gw
.

[Nyholm]

I want to keep this as a separate package because of the Common Reuse Principle.

The multipartStreamBuilder should be used by both Mailgun and Stampie. They do not require php-http/message today. Also php-http/message is quite large and it does also have some dependencies.

[sagikazarmark]

I want to keep this as a separate package because of the Common Reuse Principle.

I don't think merging this into message violates this principle.

Also php-http/message is quite large and it does also have some dependencies.

Large in terms of? The few hundred LOC is not too much IMO. Also the only dependency would be the stream filter which is relatively small.

My only concern is that we had to face with the packageception once and we decided to keep the number of packages at a minimum rate. Less maintenance, less problems.

I would like to hear other opinions about this: @dbu @joelwurtz

[dbu]

it feels like this could fit into message. its really small itself. however, this would also mean that message starts to require discovery. which would be no drama, but the more we do large packages the more everything will end up depending on everything...

then again, as we don't know yet if there will be some effort from PSR about this, i feel a separate package might be better. we can then easily deprecate the whole package but leave it around. or do a version 2 that is better, without having to bump the whole message package. or once things settled and we are sure the builder will stay the way it is, move it into message. so my vote goes to keep it separate. moving it to php-http is fine for me.
i would just declare it "experimental" to make clear we don't promise it will stay like this or be maintained if we find something else.

[sagikazarmark]

Alright then. Let's move it to the orga.