add a new client creation function to allow custom endpoint

[stumpyfr]

Useful if you need to use custom pusher server (internal usage for example)

[timonv]

This project isn't particularly maintained. I see no problem with this though. :)

[joshk]

You can transfer the project to me!

On Thu, Feb 26, 2015 at 8:58 PM, Timon Vonk [email protected] wrote:

This project isn't particularly maintained. I see no problem with this though. :)

Reply to this email directly or view it on GitHub: https://github.com/timonv/pusher/pull/10#issuecomment-76136465

[timonv]

I was just about to ping you on that!

[joshk]

I JUST PONGED!

On Thu, Feb 26, 2015 at 8:58 PM, Timon Vonk [email protected] wrote:

I was just about to ping you on that!

Reply to this email directly or view it on GitHub: https://github.com/timonv/pusher/pull/10#issuecomment-76136527

[timonv]

HOLY SHIT PREEMPTIVE PONG, YOU PSYCHIC?

check your mail

[joshk]

I'll review this shortly, thanks for the PR!

[stumpyfr]

What a reaction \o/. I started a new product with a lot of push everywhere and everything is in GO so if you need some help to keep up to date the project, I am here too.

(a PR will arrive soon on a client lib in Go too, WIP)

[timonv]

It's all transfered to @joshk now. He did like 99% more on this than me anyway :-)

[joshk]

@timonv I ALWAYS DO! :P

[joshk]

@stumpyfr thanks for the offer, I may just take you up on that.

What do you mean by client lib?

[stumpyfr]

example:

• https://github.com/Toorop/go-pusher
• https://github.com/ehq/pusher-go

currently trying and after I will change the Ctor to allow custom endpoint too

[joshk]

Ahhh, yes, would be cool to get this into this project!

On Thu, Feb 26, 2015 at 9:33 PM, Niels Freier [email protected] wrote:

example:

• https://github.com/Toorop/go-pusher

• https://github.com/ehq/pusher-go currently trying and after I will change the Ctor to allow custom endpoint too

  Reply to this email directly or view it on GitHub: https://github.com/joshk/pusher/pull/10#issuecomment-76140271

[stumpyfr]

A project who can do both (server/client) will be great yes :). working on a urgent need right now but we can start to prepare that, would be happy to help

[stumpyfr]

Here the client with the custom endpoint connection: https://github.com/Toorop/go-pusher/pull/1

[leggetter]

Just wanted to say "hi". I hope you don't mind me hijacking the thread...

Thoughts on client v server

The client (WebSocket endpoint) and server (HTTP endpoint) separation of libraries is an interesting one. One that we've been debating for years.

The separation really suits more traditional client/server technology stacks; many of which still exist and developers will continue to build them where it suits.

But I also think the separation is quite neat because they do interact with different APIs.

I can definitely see the value in having a library that uses both the libraries. A true pub/sub client. But I'd put my +1 towards keeping the two types of library separate.

We're still discussing things and it could be that we either offer an additional "authoritative" endpoint that offers full publish functionality (rather than just client events) as well as subscribe functionality. Or we may add an authentication mechanism that gives the WebSocket connection that permission.

Library naming

We've just gone through the long process of trying to establish naming conventions for the library. If you care about such things we've decided to go with the following:

• owner/service-api-lang/runtime

The constituents of this name are:

1. owner/service - for us is pusher.
2. api - is the API endpoint the library interacts with. We've gone with http for our traditional server endpoint (it's not really RESTful) and websocket for our realtime endpoint... because it's for WebSocket connections :)
3. lang/runtime is clearly for the language or runtime of the library.

Two examples are:

• pusher-http-ruby
• pusher-websocket-ruby

Library Guidelines/Checklist

We haven't started this yet. But we do plan to create a set of guidelines for the sorts of things that we'd like to see in libraries. We'll obviously adhere to these ourselves, but it's up to you if you want to do the same.

Language conventions win

I think it's important to highlight that we want to make sure that each library fits with the conventions of a language rather than trying to shoe-horn some sort of common API into each language. I know this is common-sense, but it's worth confirming.

Helping community libraries

I think we can do better at this. I'd be interested in hearing if you agree?

What would help you make the most of the Go libraries?

Happy to continue the discussion here, elsewhere or via email. [email protected]