Support Websockets in May Derby

RESOLVED INVALID

Status

RESOLVED INVALID
7 years ago
5 years ago

People

(Reporter: openjck, Unassigned)

Tracking

Details

(Whiteboard: u= c= p= )

(Reporter)

Description

7 years ago
In a recent meeting, we wondered how we would support Websocket server connections in the May Derby. Should we use some kind of Websocket service? Should we allow people to use their own servers? What about security?

We should figure this out sometime soon. At the latest, we should decide on something by mid-April so that I have time to update the copy with whatever approach we take.
Anyone building a demo using websockets would have to provide his or her own server. Mozilla won't provide that, and even if we wanted to it wouldn't happen by May. And, I don't think there's a such thing as a generic websocket service.

As far as I understand, websockets will work just fine across domains. Of course, one issue will be that we can't make any guarantees about the uptime of demos that need 3rd party servers.

That said, I think there are some decent hosting vendors that are free for low traffic servers. node.js is a good platform for that, and there's hosting at http://www.heroku.com/

What might be interesting from Mozilla's perspective is to consider hosting the websocket service for the winner of the derby. But, I don't want to presume upon IT and hosting engineers, and making that happen could take quite awhile and have a lot of devilish details.
(In reply to Les Orchard [:lorchard] from comment #1)
> And, I don't think there's a such thing as a generic websocket service.

An addendum to that: There are some hosted services out there, some free, that do useful things over websocket. These might be handy for demos that could use those as building blocks.

I found a few examples with a quick search:

http://pusher.com/
http://beaconpush.com/
http://forbind.net/

But, we might want to consider finding more suggestions - or at least making the suggestion to look for them if we don't want to endorse any in particular.
I agree we won't be able to host websocket servers ourselves.

John, I think we should recruit someone from DevEngage and/or you to write a hacks blog post describing how to set up websocket hosting on some of these providers.

If we publish the post by April 17th, we can link to it in the May dev derby content block.
Buddy's looking at websocket hosting so he might be able to suggest providers.
Not sure if this is fair / possible for the derby, but I'd love to see these two things hosted by us and featured as demos:

* BrowserQuest - browserquest.mozilla.org
* Subway, a web-based IRC client - https://github.com/thedjpetersen/subway

The first is already hosted by us, but not the other. I mention fairness because BrowserQuest would of course have to be made exempt from any prizes, but I'm not sure about the second. It might have to be exempt if we gave Subway a special advantage by hosting a server.
(Reporter)

Comment 6

7 years ago
I will be sure to mention BrowserQuest when I promote the May Derby on Hacks. Subway could be eligible to compete as long as they host it themselves. I'll plan to contact them late April.
(Reporter)

Comment 7

7 years ago
I will try to wrap this up soon. As it happens, it looks like we have until the 24th to finalize the copy, as May 1 is exactly a week after that and I usually don't change the theme until the afternoon anyway.

One point of clarification: Would a Derby participant need to host his entire demo on one of these services, or would he host one program on the Derby and one program on a Websockets service? I guess I'm confused as to how client-server socket programming works when both machines are servers. :-P
Demo on MDN would have all the client code. They will need to arrange websocket server hosting somewhere else. (Heroku, Slicehost, nodejitsu, etc.)
(Reporter)

Comment 9

7 years ago
Marking this as invalid. Seems that you guys don't have to do anything after all. Correct me if I'm wrong.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
(Assignee)

Updated

6 years ago
Version: MDN → unspecified
(Assignee)

Updated

6 years ago
Component: Website → Landing pages
Product: Mozilla Developer Network → Mozilla Developer Network
You need to log in before you can comment on or make changes to this bug.