search

joshk / pusher

Pusher server in Go
37 stars 15 forks source link

add a new client creation function to allow custom endpoint #10

Open stumpyfr opened 9 years ago

stumpyfr commented 9 years ago

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

timonv commented 9 years ago

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

joshk commented 9 years ago

You can transfer the project to me!

On Thu, Feb 26, 2015 at 8:58 PM, Timon Vonk notifications@github.com 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 commented 9 years ago

I was just about to ping you on that!

joshk commented 9 years ago

I JUST PONGED!

On Thu, Feb 26, 2015 at 8:58 PM, Timon Vonk notifications@github.com 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 commented 9 years ago

HOLY SHIT PREEMPTIVE PONG, YOU PSYCHIC?

check your mail

joshk commented 9 years ago

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

stumpyfr commented 9 years ago

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 commented 9 years ago

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

joshk commented 9 years ago

@timonv I ALWAYS DO! :P

joshk commented 9 years ago

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

What do you mean by client lib?

stumpyfr commented 9 years ago

example:

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

joshk commented 9 years ago

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

On Thu, Feb 26, 2015 at 9:33 PM, Niels Freier notifications@github.com wrote:

example:

stumpyfr commented 9 years ago

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 commented 9 years ago

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

leggetter commented 9 years ago

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:

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:

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. phil@pusher.com