Re: [go-nuts] [ANN] golem WebSocket framework

449 views
Skip to first unread message

Kiki Sugiaman

unread,
May 30, 2013, 1:46:32 AM5/30/13
to golan...@googlegroups.com
Nice, I was just about to force myself to use node.js just for this.

I'll play with the examples some more tomorrow, but I've got a few
questions after a glance.
Are you planning to add fallback transports, or will this be a purely
websocket solution?
Also, it seems like heartbeat is not yet implemented. What is Golem's
intended feature scope in terms of higher level functionalities?


On 5/29/2013 5:19 AM, Niklas Voss wrote:
> Hello fellow gophers,
> I started using Go a few months ago and had great joy using it. I
> recently finished
> the early version of a small framework to ease up WebSocket
> interactions (similar to socket.io) called golem.
>
> Feedback or even contributions are very appreciated. The project is
> currently licensed under the GPLv3,
> but I am thinking about using LGPL or Apache instead to allow more
> permissive use.
>
> The framework:
> https://github.com/trevex/golem
> Some examples:
> https://github.com/trevex/golem_examples
>
> The examples include a small chat with lobbies example and limiting
> handshake upgrades to only
> authorised sessions (using gorilla/sessions).
>
> At this point I have to thank some people, who don't know me, but
> helped in their way:
> Gary Bird - Thanks for the great WebSocket library and insights
> through your blog.
> Andrew Gallant & Kortshak - Thanks for the help on this mailing list
> with a reflection problem, that was essential for the functionality of
> the On-function.
>
> Future development will be highly dependent on feature requests and
> testing. I am planing to use generics (hopefully not opening pandora's
> box again)
> if they get implemented to get rid of runtime reflection, where it
> would improve performance.
>
> - Niklas
>
> P.S. To bring it up again feedback very appreciated.
>
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Niklas Voss

unread,
May 30, 2013, 2:27:47 AM5/30/13
to golan...@googlegroups.com
I will probably change the license to Apache sounds like the best choice.

My plan is to work the next couple of days on the documentation and implementing more configuration. 
Heartbeats are supported the inbuilt ping/pong of the WebSocket protocol is used. There is no setting to disable them though,
but I am planning to implement this at the beginning of next week.

Fallback transports are currently not planned, but on the other hand-side it shouldn't be to hard to have a fallback
for the client to use flash sockets (e.g. https://github.com/gimite/web-socket-js ).

The future is highly dependent on what people, who want to use it, need. I am planning to compare other WebSocket-
frameworks (i.e. socket.io, Atmosphere etc.) to get an overview of important features missing. Personally I am currently interested in
stress-testing golem and profiling it, before development goes further to solidify the base framework.

-Nik

Niklas Voss

unread,
May 30, 2013, 6:13:48 AM5/30/13
to golan...@googlegroups.com
Just wanted to give an update on a few things:

1. I got distracted and implemented an example using gimite's flash fallback. The example forcefully falls back to flash:
And the backend illustrates how to serve the flash policy as well:

2. The license is now officially Apache 2.

More documentation and some wiki-pages with tutorials will come the next couple of days.

-Nik

Niklas Voss

unread,
Jun 10, 2013, 9:01:07 AM6/10/13
to golan...@googlegroups.com
Another update:

I was busy the past week polishing the documentation, adding guides and wiki articles and new features:

There are now several tutorials / guides on how to utilise certain features:

The main feature is that the communication protocol is interchangeable. An example is provided where BSON and WebSocket 
binary operations are used instead of the default JSON-based approach.

More informations can be found on github.

I would love to hear feedback on the API design, especially on the "Protocol"-interface, which custom protocols have to implement. 
I was quite undecided how to name things there. My main concern currently is that "Protocol" as an interface name is not go idiomatic.

-Nik
Reply all
Reply to author
Forward
0 new messages