Future of the project about httplug HOT 33 CLOSED

very cool. i think the terminology branch is pretty much ready with the exceptions coming good. i hope we get some more people to look over it before going alpha but either way a first alpha end of september seems a good idea.

i think my main concern at this point is the name of the thing. while PHP HTTP is a bold but justified claim, it is about the worst thing possible in terms of SEO :-/ try googling for "php http" and you will find about every web related website ever written. so we might need some more unique extra name that we use in descriptions and the documentation website so there is a chance to actually find this. (this does not need to be in the github organisation or such, and lets leave the namespaces alone of course.). not sure if we should change the composer package name though. if @egeloen would agree we could keep the name Ivory if that makes sense, or pick something else.

from httplug.

👍 for finding a better name. The basic idea with PHP HTTP was that it is a general organization for any HTTP related PHP project. Our main product currently is this adapter/client thing. As far as I know Ivory is rather a vendor (see IvoryCkeditorBundle) which is why we agreed to find a better name.

I would also like more people to review the interface before release, but I am not sure which is the best way to achieve that. Where should we "advertise" ourselves?

from httplug.

Where should we "advertise" ourselves?

Friends of PHP, Friends of Symfony, The PHP League, PHP-FIG, conferences, #phpc, ...?

from httplug.

👍 I like the idea, although I am not invloved in all of those projects/teams. I am going to write an email to the League maillist, because I know those guys.

from httplug.

@hannesvdvreken If you also agree, I would like to invite @dbu and @ddeboer to the team, if they would like to join. They did an amazing work so far, which I would like to thank here as well.

from httplug.

Yes, I agree :-)

No need to wait for my permission, but thanks for letting me know ;-)

from httplug.

Well, it's not a question of permission, but a question of majority. Currently there are four people in the team, you and me are active in the project. I don't want to make decisions like this alone.

from httplug.

Understood

from httplug.

I’m in favour of reaching alpha as quickly as possible. We can leave out some adapter implementations and tweaks if that saves time. Instead, we should focus on making the docs more complete and user-friendly; they are currently written largely from an author's perspective. Having good docs invites people to try out the library and supply feedback on how to move forward.

I agree that the organisation name does not help in terms of SEO (fortunately, searching for php http adapter yields better results). Let’s drop Ivory, also to make clear this library is more a rewrite than a continuation of that library. It might make sense to have ‘adapter’ (or some metaphor for it) in the name, as that's really what the library is about. I’ll have to think a bit about a better name, though. 😉

from httplug.

they are currently written largely from an author's perspective.

Well, I am not really good at documentation

It might make sense to have ‘adapter’

Actually client might fit better, because after the refactoring we did in the last few weeks, it is rather a general client implementation for PSR-7. I am open to any suggestion for names. :)

Actually I would like to concentrate on the interfaces for the alpha, and provide one or more implementations.

from httplug.

After the terminology branch is merged, we are ready for the first alpha I think. Or at least for a review phase.

So we should have a name then. My plan is to rename this repository to the new name and repush it again as adapter, becasue a few packages already rely on it. The reason of renaming is to preserve history and issues.

from httplug.

The packages that rely on this are also not stable, so a simple PR can solve any breaking package dependency links.

from httplug.

Right. What I am sure of is the renaming, repushing can be omitted. But we also have to ask @Seldaek to remove php-http/adapter from packagist then.

from httplug.

You can mark it as abandoned and point to the new name whenever you figure one out. I can delete later when it's not in use anymore.

from httplug.

Thanks!

from httplug.

from httplug.

As far as I know Packagist allows us to see what packages depend on adapter. If there are none, or all of those are ours, then we are safe to get rid of it.

from httplug.

from httplug.

These sounds good. I imagine a name something like diactoros. It sounds good. I don't know if it has a meaning at all.

Maybe if we insert a few vowels in CPHC we get a name which sounds good. ;)

from httplug.

Unfortunately "client" translated to other languages is similar to the english word in most cases.

from httplug.

In Dutch: "Klant" 😛
On 22 Sep 2015 8:16 pm, "Márk Sági-Kazár" [email protected] wrote:

Unfortunately "client" translated to other languages is similar to the
english word in most cases.

—
Reply to this email directly or view it on GitHub
#45 (comment).

from httplug.

Sounds good 👍

from httplug.

from httplug.

Do you mean Klant for the organisation or the repo name? The latter would be a bit weird (klant/client), at least for Dutch people.

The word ‘klant’ is perfectly fine, though of course for devs there may always be a slight reminder about the love/hate relationship with clients (customers). 😉

from httplug.

I think it might be php-http/klant.

from httplug.

I see. Unfortunately I haven’t been able to keep up with all developments here lately, but it seems the client package will become the central one, dropping the adapter name. Is that right? I guess we will keep the *-adapter packages, and that they then become adapters between their respective clients (Guzzle etc.) and the PSR HTTP client provided (as an interface) here.

from httplug.

Right. The reasoning behind is that from a user point of view, it is absolutely irrelevant whether it is an adapter or an actual client. This way the possible usage of adapter/client interface is not that limited.

from httplug.

Agreed: user projects and frameworks should only have to depend on a (generic) HTTP client.

from httplug.

Yeah. This also opens the way to a possible future PSR.

from httplug.

"klant" was a joke at first, but if you look at it, if ticks some of the boxes of a good name:

• it's googleable (in combination with the terms php and http)
• it would be unique on packagist
• it's pronounceable in a lot of languages because it's a simple 5 letter word with 1 syllable

If someone comes up with a different name: I'm all cool with that.

from httplug.

Jokes usually become the best ideas. 😉

I don't have a problem with it and I can't come up with anything better. We can leave this question open until the first alpha, see if anyone can come up something better. Let's continue this discussion in #53

from httplug.

anything left to discuss here? i suggest we create new issues if there is anything left open that is not covered by a specific issue.

from httplug.

Agreed.

from httplug.