socketstream / socketstream

A framework for Realtime Web Apps

NOTICE - NO LONGER WORKED ON

Hi, SocketStream isn't maintained anymore, but the code is here for anyone who wants to take a look.

There are lots of other Node.js web application frameworks out there, please consider those instead for building your applications.

Paul Jensen, Wednesday 15th May, 2019.

SocketStream

Introduction

SocketStream is a framework for Realtime Web Apps

Latest release: 0.5.3 unstable (view changelog)

Live demo | Documentation

For existing SocketStream installations you may want to remain on 0.4.5 for a while. It is the most backwards compatible and robust and well covered by tests. It should be ready for production.

The coming releases will see a lot of changes to accommodate new transport options modern browsers and mobile apps. The API will remain largely the same, but there are bound to be some changes.

Installation

npm install -g socketstream

Usage

socketstream new <your_app_name>
cd <your_app_name>
npm install
npm start

Then open a web browser at localhost:3000:

open http://localhost:3000

Upgrade from 0.3 or 0.4 to 0.5

To make SocketStream more stable some major dependencies have been moved out. Please add these modules to package.json.

• socketstream-cookie-session: 0.5.x
• engine.io: 1.5.2
• engine.io-client: 1.5.2
• redis: 0.12.1
• connect: 3.4.0

Why SocketStream?

The Real-Time web has been touted for years, and it is very much in use. However there remains a number of challenges that have not been solved. Web Sockets will remain an important technology for delivering a live experience on your website or mobile app. However with HTTP/2 and WebRTC other options come into play. SocketStream will help you to mix and match depending on what you aim to build.

It gives you tools to manage your project:

• Providing a sensible place to put everything
• Accelerating deployment with integrated asset packing and CDN support
• Production Deployment skeleton
• Good debugging output

Integration points:

• Accelerating development with Live Reload and (optional) support for Stylus, Jade, and other transpilers.
• Add-ons can be dropped in without configuration needed picking between Cookie and Token based auth.

Easy progression from REST

A good REST API will remain the right solution for many scenarios. Web pages will remain based on HTTP. Streaming is pixie dust sprinkled on top. SocketStream will be refactored to support a gradual addition on pixie dust keeping the REST structure as the central point.

Batteries included:

• Dependencies are peer, so you pick the versions you want to use.
• Built-in CommonJS bundler (ES6 on-the-way)
• Built in formatter integration for: Sass, LESS, Stylus, Jade, Hogan
• Built in template engine integration for: HTML5, React, Angular, jQuery
• Built in transport integration for: Socket.io and SockJS
• Examples

Building a simple chat app that uses websockets is easy, but rich, non-trivial, responsive realtime UI without ending up with a mess of code is hard SocketStream eases the pain by:

How to

• Base the application on Connect and Engine io
• Base the application on Express and SockJS
• Make a minimal application like SocketStream 0.3
• Serve HTTP resources and pages
• Choosing the right Streaming Protocol

Applications using SocketStream

• Dashku: Realtime dashboards and widgets using HTML, CSS and JavaScript. Also hosted at dashku.com.
• SketchDeck: An app for designing great slide decks from sketches, also a Y Combinator tech startup.
• Hollow: An interactive, emmy-nominated documentary.
• Bitjoy: Realtime Bitcoin prices and news.
• Teeleader: A booking engine for Golf courses.

Presentations

• SocketStream (November 2013): On Slideshare and SpeakerDeck.
• SocketStream (July 2015): On SpeakerDeck.

Videos

(most recent at end)

• KrtConf.com, Portland, November 2011
• LNUG.org, London, May 2012
• LXJS, Lisbon, September 2012
• RealtimeConf, Portland, October 2012
• QCon, San Francisco, November 2012
• RealtimeConf EU, Lyon, April 2013

Documentation

Checkout the documentation here.

Team

Owner: Henrik Vendelbo

Original Creator: Owen Barnes

Core Contributors:

• Paul Jensen
• Roman Minkin
• Robert Hall
• Joshua Cullick

Contact

• Twitter: @socketstream
• Chat: Gitter

License

SocketStream is released under the MIT license.

socketstream's Issues

Include app/shared code before app/client and app/server code?

I want a model in SS.client.myApp.Models to inherit from SS.shared.myApp.Models. Currently, this doesn't seem to be possible because the scripts are added to the browser in the opposite order.

Is there a way I can do this?

exports.authenticate = true doesn´t seem to work

in app/server/distributors.coffee

first line

exports.authenticate = true

exports.actions =
distributors_all: (cb) ->

access to session from custom HTTP middleware

I'm trying to implement openid authentication using custom HTTP middleware:

1. A user submits openid authentication form using plain old HTTP POST
2. The middleware intercepts the POST and returns a 301 redirect to an OpenID Server
3. The openid server redirects back to the url I provided
4. The redirected GET is intercepted by my custom middleware
5. The middleware authenticates the user
6. The middleware returns a 301 redirect to / so our single-page app starts up again

The problem is that step 5 cannot be completed because I don't see a way to access sessions from HTTP middleware.

Is there any?

socketstream new test fails

It seems not to find argsparser module (Mac OS X Snow Leopard):

[piotr@Vaygr] ~/Work/Github ruby-1.9.2-p136 $ git clone https://github.com/socketstream/socketstream.git
Cloning into socketstream...
remote: Counting objects: 1273, done.
remote: Compressing objects: 100% (387/387), done.
remote: Total 1273 (delta 822), reused 1265 (delta 820)
Receiving objects: 100% (1273/1273), 314.20 KiB | 275 KiB/s, done.
Resolving deltas: 100% (822/822), done.
[piotr@Vaygr] ~/Work/Github ruby-1.9.2-p136 $ cd socketstream/
[piotr@Vaygr] ~/Work/Github/socketstream master ruby-1.9.2-p136 $ npm link
npm info it worked if it ends with ok
npm info using [email protected]
npm info using [email protected]
npm info link /Users/piotr/Work/Github/socketstream
npm info range socket.io@= 0.6.17
npm info range hiredis@= 0.1.8
npm info range redis@= 0.5.9
npm info range node-static@= 0.5.3
npm info range argsparser@= 0.0.4
npm info range jade@= 0.10.3
npm info range semver@= 1.0.1
npm info range stylus@= 0.11.1
npm info range uglify-js@= 0.0.5
npm info fetch http://registry.npmjs.org/socket.io/-/socket.io-0.6.17.tgz
npm info fetch http://registry.npmjs.org/hiredis/-/hiredis-0.1.8.tgz
npm info fetch http://registry.npmjs.org/redis/-/redis-0.5.9.tgz
npm info fetch http://registry.npmjs.org/node-static/-/node-static-0.5.3.tgz
npm info fetch http://registry.npmjs.org/argsparser/-/argsparser-0.0.4.tgz
npm info calculating sha1 /var/folders/5y/5yebgGx2F+8YtZoogVpYnE+++TI/-Tmp-/npm-1303246188737/1303246188889-0.7908729098271579/tmp.tgz
npm info shasum 018156774f802a56f367d826e9a855db6d45d220
npm info fetch http://registry.npmjs.org/jade/-/jade-0.10.3.tgz
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/hiredis/0.1.8/package.tgz
npm info shasum 0321cd4b7abe7588f4fad56b3edb623e271822e2
npm info calculating sha1 /var/folders/5y/5yebgGx2F+8YtZoogVpYnE+++TI/-Tmp-/npm-1303246188737/1303246189374-0.16509577492251992/tmp.tgz
npm info shasum ad416bd94f18e661fc81d6e292c58e6235a75abe
npm info calculating sha1 /var/folders/5y/5yebgGx2F+8YtZoogVpYnE+++TI/-Tmp-/npm-1303246188737/1303246189059-0.7747357517946512/tmp.tgz
npm info shasum 742d3a20b9fea9d86183308ec5363a04ea7a6634
npm info fetch http://registry.npmjs.org/semver/-/semver-1.0.1.tgz
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/argsparser/0.0.4/package.tgz
npm info shasum f7509541e4bb5df1f4b549747a72f36841922d03
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/node-static/0.5.3/package.tgz
npm info shasum 2e70b4fe5036d4aa3192db098a560ddf9f92f88c
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/redis/0.5.9/package.tgz
npm info shasum 05fed07c9261d814f99a22c5ab97b04b72725cad
npm info fetch http://registry.npmjs.org/stylus/-/stylus-0.11.1.tgz
npm info calculating sha1 /var/folders/5y/5yebgGx2F+8YtZoogVpYnE+++TI/-Tmp-/npm-1303246188737/1303246189953-0.8706767787225544/tmp.tgz
npm info shasum 93b90b9a3e00c7a143f2e49f6e2b32fd72237cdb
npm info fetch http://registry.npmjs.org/uglify-js/-/uglify-js-0.0.5.tgz
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/semver/1.0.1/package.tgz
npm info shasum e847efeaa6822e0ad903a39e11966b871a31c8ec
npm info calculating sha1 /var/folders/5y/5yebgGx2F+8YtZoogVpYnE+++TI/-Tmp-/npm-1303246188737/1303246189676-0.3631220832467079/tmp.tgz
npm info shasum 063749f8c9f0931ca0fa259747ee7c485e113773
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/jade/0.10.3/package.tgz
npm info shasum d62b3022cceb1988f9e9ed8a79d8f266546a7f23
npm info calculating sha1 /var/folders/5y/5yebgGx2F+8YtZoogVpYnE+++TI/-Tmp-/npm-1303246188737/1303246190192-0.0876075723208487/tmp.tgz
npm info shasum 8aa94a8e82f88b955ed828c5b93715b61072a6d5
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/stylus/0.11.1/package.tgz
npm info shasum 62a1517118c0de91bdc9c4d0cc3cc7e9503b84c3
npm info calculating sha1 /var/folders/5y/5yebgGx2F+8YtZoogVpYnE+++TI/-Tmp-/npm-1303246188737/1303246190346-0.8866962159518152/tmp.tgz
npm info shasum c40d18e51784a230477bb0354fa415ec361dba5e
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/uglify-js/0.0.5/package.tgz
npm info shasum fe149acbf17d9fd97fd30287d7d68f464846140d
npm info fetch http://registry.npmjs.org/cssom/-/cssom-0.2.0.tgz
npm info fetch http://registry.npmjs.org/growl/-/growl-1.1.0.tgz
npm info calculating sha1 /var/folders/5y/5yebgGx2F+8YtZoogVpYnE+++TI/-Tmp-/npm-1303246188737/1303246191673-0.48466554656624794/tmp.tgz
npm info shasum 93808dd6df4e336785d5213b9d47c5047f363623
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/growl/1.1.0/package.tgz
npm info shasum 9828484444cc30abce627c14132ffaf8b8b27490
npm info calculating sha1 /var/folders/5y/5yebgGx2F+8YtZoogVpYnE+++TI/-Tmp-/npm-1303246188737/1303246191437-0.42966150818392634/tmp.tgz
npm info shasum beae359be7ccba82daf9c4cb89252b497e563964
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/cssom/0.2.0/package.tgz
npm info shasum 5d2afbeee4e1223790040c6188ec537884404f05
npm info calculating sha1 /var/folders/5y/5yebgGx2F+8YtZoogVpYnE+++TI/-Tmp-/npm-1303246188737/1303246188737-0.6366334587801248/tmp.tgz
npm info shasum ca9a480df1e61d84d555e98e299ab51674ced90a
npm info calculating sha1 /usr/local/lib/node/.npm/.cache/socket.io/0.6.17/package.tgz
npm info shasum 32206b0784ff49bd26c12157aec435b23ada1c95
npm info preinstall [email protected]
npm info preinstall [email protected]
npm info preinstall [email protected]
npm info preinstall [email protected]
npm info preinstall [email protected]
npm info preinstall [email protected]
npm info preinstall [email protected]
npm info preinstall [email protected]
npm info preinstall [email protected]
npm info preinstall [email protected]
npm info preinstall [email protected]
Setting srcdir to                        : /usr/local/lib/node/.npm/hiredis/0.1.8/package 
Setting blddir to                        : /usr/local/lib/node/.npm/hiredis/0.1.8/package/build 
Checking for program gcc or cc           : /usr/bin/gcc 
Checking for program cpp                 : /usr/bin/cpp 
Checking for program ar                  : /usr/bin/ar 
Checking for program ranlib              : /usr/bin/ranlib 
Checking for gcc                         : ok  
Checking for program g++ or c++          : /usr/bin/g++ 
Checking for g++                         : ok  
Checking for node path                   : not found 
Checking for node prefix                 : ok /usr/local/Cellar/node/0.4.6 
'configure' finished successfully (0.657s)
Waf: Entering directory `/usr/local/lib/node/.npm/hiredis/0.1.8/package/build'
[1/7] cc: deps/hiredis/sds.c -> build/default/deps/hiredis/sds_1.o
[2/7] cc: deps/hiredis/net.c -> build/default/deps/hiredis/net_1.o
[3/7] cc: deps/hiredis/hiredis.c -> build/default/deps/hiredis/hiredis_1.o
[4/7] static_link: build/default/deps/hiredis/sds_1.o build/default/deps/hiredis/net_1.o build/default/deps/hiredis/hiredis_1.o -> build/default/libhiredis.a
[5/7] cxx: hiredis.cc -> build/default/hiredis_2.o
[6/7] cxx: reader.cc -> build/default/reader_2.o
[7/7] cxx_link: build/default/hiredis_2.o build/default/reader_2.o -> build/default/hiredis.node
Waf: Leaving directory `/usr/local/lib/node/.npm/hiredis/0.1.8/package/build'
'build' finished successfully (4.267s)
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info install [email protected]
Run tests...
All tests ok
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info build Success: [email protected]
npm info build Success: [email protected]
npm info build Success: [email protected]
npm info build Success: [email protected]
npm info build Success: [email protected]
npm info build Success: [email protected]
npm info build Success: [email protected]
npm info build Success: [email protected]
npm info build Success: [email protected]
npm info build Success: [email protected]
npm info build Success: [email protected]
npm info preinstall [email protected]
npm info install [email protected]
npm info postinstall [email protected]
npm info preactivate [email protected]
npm info activate [email protected]
npm info postactivate [email protected]
npm info build Success: [email protected]
npm ok
[piotr@Vaygr] ~/Work/Github/socketstream master ruby-1.9.2-p136 $ cd ~
[piotr@Vaygr] ~ ruby-1.9.2-p136 $ socketstream new test

node.js:134
        throw e; // process.nextTick error, or 'error' event on first tick
        ^
Error: Cannot find module '[email protected]'
    at Function._resolveFilename (module.js:320:11)
    at Function._load (module.js:266:25)
    at require (module.js:348:19)
    at Object.<anonymous> (/Users/piotr/Work/Github/socketstream/bin/socketstream:6:21)
    at Module._compile (module.js:404:26)
    at Object..js (module.js:410:10)
    at Module.load (module.js:336:31)
    at Function._load (module.js:297:12)
    at Array.<anonymous> (module.js:423:10)
    at EventEmitter._tickCallback (node.js:126:26)

Hiredis dependency

Can the hiredis dependency be removed or made optional?

When I port socketstream to work on Cloud9IDE, I need to manually edit the package.json to take out the hiredis dependency. As I understand it, this is an optional driver to run node_redis. This means there is no explicit requirement for the dependency.

Thoughts?

zmq build error (install fails)

https://gist.github.com/1102772

Ubuntu 11.04 (64 bits)

A predefined folder for server-private libraries is needed

The modules in /server folder are all exposed to the client. So the code which is not intended for exposure must be put somewhere else and no folder for that seems to exist.

I understand that the /vendor folder is for third-party server-side libraries and not for our own code.

zeromq library was renamed to zmq

The zeromq 0.5.1 is very old and cannot even be built out of the box on Cygwin because of reliance on outdated syntax of node-waf.

So at some point we should migrate no zmq which is developed by the same author and resides in the same github repository.

Client-Side Coffee/JS Dependency Ordering

As I understand it, if you want to specify the inclusion ordering of your coffeescript/JS on the client, you need to prefix the filenames with numbers, e.g. 1.foo.coffee, 2.bar.coffee, etc. This seems a bit cumbersome. Maybe it would be better if there were a file in the config directory where you could specify the order. Something like:

# config/assets.coffee

exports.assets =
  client: [
    'app.coffee',
    'models/foo.coffee',
    'models/bar.coffee',
    'views/foo-view.coffee',
    'views/bar-view.coffee'
  ]

  lib: ['helpers.js', 'zepto.js', 'underscore.js', 'backbone.js']

I realize then you would have to manually edit this file whenever you want to add a new file, but I still think this is far preferable to managing filenames when the number of files grows large and you need to modify the ordering.

Non-exposed server methods

I want to create a server method that is not exposed to the clients, but accessible from other namespaces -- is this possible?

For example, from within /app/server/Foo.coffee

I want to be able to call the method SS.server.bar.myMethod(). However, I don't want bar.myMethod() to be exposed in the API (and possibly not have to pass it a callback).

An issue with jQuery templates

Just noticed, scripts generated for templates have type 'text/html', but in different manuals for jQuery templates said that type must be 'text/x-jquery-tmpl' or any other different from usual types.
It is made for browsers to ignore content of this script (and don't process it as usual javascript).

Trouble with flashsocket in default ports

If socketstream runs on default ports (80 for http or 443 for https) and browser is trying to use flashsocket, then browser couldn't get a flashsocket file from server, for example this is error, we have cought in Opera:
[WebSocket] SYNTAX_ERR: invalid url: ws://platform:/socket.io/flashsocket
I think this problem may be in socket.io in function WS.prototype.prepareUrl, but i'm don't really sure.

Support SEO

One of the biggest problem for a Single-page application is SEO, this is Google's solution:
http://code.google.com/intl/zh-CN/web/ajaxcrawling/docs/getting-started.html

Array.prototype.any might not be a good idea

Hey!

Given that Array in JS 1.6 has every and some, including any with completely different semantics might not be a good idea. Besides, checking length does exactly the same as calling any, and IMO that should be considered an JS idiom.

See: https://developer.mozilla.org/en/New_in_JavaScript_1.6#Array_extras

Calling server functions with more than two args results in error

When i call SS.server.app.method(arg1, arg2, cb) from the client, with a server-side function that expects those three arguments, i get "app.method: 'arg1'...Error: The method action expects params but none were sent". So far I've gone around this by just passing an options object and the callback, but it still seems like a weird behavior.

Nodemon and socketstream

Is there a way to get nodemon (or some similar module) to work with socket stream. In development, it would be nice if the server automatically restarted on changes to certain files.

Furthermore, is there a way to make it so that in production the server automatically restarts upon crashing.

Problem running socketstream on both ubuntu and debian

I tried installing socketstream about 6 times on clean system (cloud).
I used script, provided by this community. Tried doing it line-to-line or creating a ./ss.sh. Even tried to build all parts of source manually.
Here is error i get every time I start test app:

17 Jul 19:51:24 - Starting SocketStream server...

/root/local/node/lib/node_modules/socketstream/node_modules/stylus/lib/visitor/evaluator.js:539
Evaluator.prototype.visitImport = function(import){
^^^^^^

node.js:189
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: Unable to start SocketStream as we're missing stylus.
Please install with 'npm install stylus'. Please also check the version number if you're using a version of npm below 1.0
at /root/local/node/lib/node_modules/socketstream/lib/main.coffee:206:19
at Array.forEach (native)
at Object.externalLibs (/root/local/node/lib/node_modules/socketstream/lib/main.coffee:192:201)
at Object.project (/root/local/node/lib/node_modules/socketstream/lib/main.coffee:98:12)
at Object.server (/root/local/node/lib/node_modules/socketstream/lib/main.coffee:69:12)
at Object.process (/root/local/node/lib/node_modules/socketstream/lib/main.coffee:48:30)
at Object. (/root/local/node/lib/node_modules/socketstream/bin/socketstream:11:44)
at Module._compile (module.js:420:26)
at Object..js (module.js:459:10)
at Module.load (module.js:335:31)

socketstream should error on invalid chars in script names

I put a script named app\client\new-2x2-layout.js and socket stream added the following prologue code to my script:

if (typeof(SS.client.new-2x2-layout) == 'undefined') SS.client.new-2x2-layout = {};

The code is obviously an incorrect piece of javascript as minus sign cannot be a part of identifier. So either socketstream should issue a fatal error or should use SS.client['new-2x2-layout'] in the prologue.

"public/assets/" requires manual deletion of compiled files to pickup changes

If I add additional files to:

/lib/client/
/lib/css/

The docs specify that these changes will be detected upon a server restart and recompiled. This behaviour does not occur until I manually delete the files stored under /public/assets/

Best way to create namespaced libs?

I had some files named shared/Foo.coffee and shared/Foo.Bar.coffee, but the compiler for the browser didn't like the files with dots in the names.

Do you folks have any suggestions for the best way to separate a large namespace? I want all my models namespaced in Foo.Models, but I'd like the ability to potentially split up modules into separate files as they get larger.

Undesired consumption of .svn directories at runtime

Hi All

We're just playing with the very snappy and exciting looking stuff here and we took a simple test app, got it working and then shared it internally on SVN. At which point it all went a bit funny. (Sadly not all of us can live out of Github :)

Turns out that Socketstream is picking up on the .svn directories. We were able to make a fix in main.coffee to prevent the initial tree from getting choked up with that content

# Turns directories into an object tree
fileTrees: ->
    ['client','shared','server','models'].map (api) ->
     try
       list = file_utils.readDirSync("#{SS.root}/app/#{api}")
       list = filterSvn(list)
     catch e
       {}

...

filterSvn = (files) ->
  for key, fileList of files
    filteredList = []
    fileList.forEach (file) ->
      if file.indexOf('.svn') == -1
        filteredList.push(file)

    files[key] = filteredList
return files

...

but even after that somehow Socketstream is managing to find the directory contents and it seems as though it's trying to turn the svn folder + file into a namespaced value. Eg: app/shared/.svn/all-wcprops leads to the following error when you visit the default new app that gets created by socketstream (and which is committed to svn)

TypeError: Property 'svn-all-wcprops' of object # is not a function

We tried upping the log level to 4, but no extra info comes out.. Also tried looking for where in the system you deal with uncaught exceptions, and try to boost it a bit by adding a stack trace... Again, we couldn't track it down...

process.on('uncaughtException',function(e) {
   sys.log("Caught unhandled exception: " + e);
   sys.log(" ---> : " + e.stack);
});

Any suggestions where we should look to find the culprit which is reading the .svn directories? Once we get it working will update our fork

Cheers

J

Error: EPIPE, Broken pipe

This could be a problem with a dependency, such as Socket.IO ... I'm new to node :\

Note: This only happens with HTTPS

If I sit in a browser and hold in Command-R (reload), after a couple refreshes the server dies with the error:

node.js:134
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: EPIPE, Broken pipe
at Socket._writeImpl (net.js:159:14)
at Socket._writeOut (net.js:450:25)
at Socket.write (net.js:377:17)
at EncryptedStream.ondata (stream.js:36:26)
at EncryptedStream.emit (events.js:64:17)
at EncryptedStream._push (tls.js:299:12)
at SecurePair.cycle (tls.js:581:20)
at CleartextStream.write (tls.js:96:13)
at ServerResponse._writeRaw (http.js:391:28)
at ServerResponse._send (http.js:371:15)

My guess is that a socket is closed but something (net.js?) is attempting to write to them anyway

iPhone fullscreen Safari app should be a compatible browser

On an iPhone (or the simulator), when you add a socketstream page to your homescreen and then try to open it, the Incompatible Browser page shows up.

The UserAgent must be different somehow (I haven't looked into it that far yet).

IRC channel

Hi all SocketStream users!

I've played with SS for some time now, but it lacks one basic feature: an IRC channel! I joined #socketstream on freenode today, only to find one other person, and now I'm all alone again. How about featuring the channel in the github readme?

Hope you'll join me in there! :-)

• Olav

Linode StackScript

I'm going to provide a Linode StackScript that will setup a Linode instance to work with a socketstream app out of the box.

0.2p socketstream start error

0MQ installed

download the tar,

in a new project run socketstream s

get this error after

------------------------------ SocketStream ------------------------------
Version 0.2.0preview running in development on PID 7681
Primary web server listening on http://0.0.0.0:3000

Spawned 1 back end worker process (PID 7683)

Sorry, I do not know how to backend-worker. Type "socketstream help" to see a list of commands.
Sorry, I do not know how to backend-worker. Type "socketstream help" to see a list of commands.
......lots of it.

9e4cfb9

Debugging methods

I typically use node-inspector for debugging my node apps: https://github.com/dannycoates/node-inspector

However, when starting a socketstream server I can't pass in a --debug param like a normally do to enable debugging. Can this be added or are there alternative methods for debugging?

Set dynamic (coded) config options

For those of us developing in an environment such as Cloud9IDE, we need to assign the web port to the value of process.env.C9_PORT. This value changes on each run.

It would be nice to have a facility to make coded changes to the config options. Alternatively, why not have the config file simply be a coffeescript file that exports a config object?

js file that contains Chinese characters, an error occurred

//app/client/app.js
exports.init = function(){
var ss= '测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试';
SS.server.app.init( function(response){
});
};
in firefox:
[17:30:41.046] unterminated string literal @ http://192.168.1.107:3002/client/app.js:5
content:

if (typeof(SS.client.app) == 'undefined') SS.client.app = {};
// Client-side Code

SS.client.app.init = function(){
var ss= '测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测

Support for named alternate stylesheets

Is it possible to have several different concatenated stylesheets and use "alternate stylesheet" syntax?

<link type="text/css" rel="alternate stylesheet" media="all" title="Smoothness" 
href="/jqueryui/1.8.11/themes/smoothness/jquery.ui.all.css">

As most users will use the default CSS theme, to minimize latency it is a good idea not to have a separate URL for CSS common for all themes, but to have common css concatenated with theme CSS.

Also, there are theme-specific images and theme CSS files use relative URLs to refer to those images.

If these alternate stylesheets are not currently possible, I propose the following:

If /app/css doesn't have subfolders then work like now.

If there are subfolders, subfolder names should be treated as theme names and exposed as @title attribute for alternate stylesheets.

Each alternate stylesheet should be served as /theme_name/theme.css (this is useful for theme-local images as we can put th images to /public/theme_name/)

Each alternate stylesheet should be the result of concatenation of all stylesheets in the theme folder. Iif some CSS common for all themes is required, that can be achieved by server-side @import.

Opera and Socketstream will work fine

Kind'a meta issue but nevertheless. It should be pointed out that socketstream (apps) runs fine on Opera 11+ with websocket enabled. Just do ; Type or paste opera:config#Enable%20WebSockets in the address bar and press enter. This should be reflected in the SS demo apps too. However, Opera for some reason do not like the flashsocket backup in socket.io

As I said, kind of a meta issue but I think it should be noted in the docs/readme.

/t

app.init() is called too late

app.init() is called only when socketstream has been initialized. So a quick-starting application needs three entry points:

1. as early as possible
2. when DOM is ready
3. when both DOM and SS are ready

The first entry point is needed if an application is going to perform some computationally hard work which is independent of DOM and SS. Yes, things like client-side Diffie-Hellman KEX or decompression are not uncommon these days.

The second entry point is needed much more often and is widely understood ($(function () {})

The third point is already implemented by app.init

The first two can be easily implemented by app developer without any support from SS. But I think the applications will look more structured if all the three points are standardized (have standard names and locations) and are not scattered around the source of app.js.

What do you think? Should we have app.domready and app.load in addition of app.init, or current situation is by design?

Client-side CommonJS modules

Currently we have an asymmetry: files in /server folder are proper CommonJS modules, but files in /client folder are just piles of javascript which are concatenated together as an opaque BLOBs by Asset Manager.

This creates scalability issues for larger applications. I found myself using a so called Module Pattern in every file in /client:

var module_name = function ()
{
     var bar = ...
     var baz = function () { ... }
     var quux = function () { ... }

     return { quux : quux }
}()

So later I can use module_name.quux() and bar and baz don't pollute the global namespace but moreover completely private and inaccessible from outside.

There is obviously boilerplate code which can be eliminated the following way I propose:

1. Every file in /client has a CommonJS module identifier coinciding with its filename and path. E.g. /client/foo/bar.js has foo/bar as the identifier.
2. The Asset Manager creates the following wrapper against each file:

var internal_module_var = function () {
   var exports = {}
   var require = SS.resolve_relatively_to('foo/bar')

   (file_contents_goes_here)
   return exports
}()

The global internal SS.resolve_relatively_to() function returns a require function to use for each module, so require('../bar') means different things in different modules because the module id is, well, relative.

The require function maintains a dictionary of absolute module ids and internal module variables, and the first time a module is required its function is executed so initialization actions take place and exports are saved in the same dictionary.

This integrates fancily with proposed onload/domready events and make client and server code completely symmetrical because require and exports work on both sides.

Feature Request: A simple API to implement crawlable single-page websites

The requested feature would allow one to build a complete single-page website using SocketStream without losing any SEO ability.

The following page describes a specification that Googlebots use for indexing pages that were dynamically generated using JavaScript: http://code.google.com/web/ajaxcrawling/docs/specification.html

The spec requires the server to generate HTML snapshots from the hash fragment. It seems to me that one would simply map the hash fragments to pages and pass "query parameters" as normal, too. For example: http://example.com/#!/contact?foo=bar would tell the client-side JavaScript to request the contact.jade or contact.html page with the query parameters foo=bar. Google would retrieve this HTML snapshot by requesting http://example.com?_escaped_fragment_=contact?foo=bar. Of course, some of the characters in this request will be escaped (i.e. the question mark).

The app.jade file could be configured to plop in the correct HTML depending on the request. The client-side and server-side JS would also be able to handle state information using the "query parameters" passed into the hash fragment. Furthermore, one can use client-side JS to monitor the contents of the hash fragment to fire an event when its value changes (See jQuery BBQ - http://benalman.com/code/projects/jquery-bbq/docs/files/jquery-ba-bbq-js.html). Finally, browser history can be preserved, as many browsers' back/forward buttons will work on changing hash fragments. You can see this in action for apps like Gmail.

A possible implementation might allow a user to create multiple views (index.jade, about-us.jade, contact.jade, etc.) There might also exist many jade template files (i.e. /views/templates/layout1.jade, etc.) When the user hits /, the app.jade file is rendered by SocketStream, loading the default template (/views/templates/default.jade). Somewhere in the template, a function is called to render the index.jade view. When links are followed (i.e. #!/contact), the client-side JS will request the page from the server and plop it into some sort of div container (i.e.

). This div container must be in the template.jade file. One could also allow the contact.jade view to handle its own "query parameters" in the hash fragment by parsing those parameters and sending them to the view at render-time.

This whole process might be a bit slow, so if anyone has a better or more elegant implementation idea, that works, too.

Syntax highlight in *.md

Hi, just a quick issue that's a suggestion, really: you may want to use

// the code
var foo = "bar"

which renders as

// the code
var foo = "bar"

instead of indentation, so as to benefit from syntax highlighting; especially in the README.md file. Github leverages Pygments which support CoffeeScript, so everything should turn colorful in a bliss.

Keep the good work going :)

Handle Mac OS X Dashboard Web Clip User Agent

Bart was trying to embed a Dashboard Web Clip containing a widget from ssdashboard.com, but the screen rendered an "incompatible browser" message. It looks like the http_browser_midddleware is not matching. I will look into this further.

Replace `exports` on right hand side for convenience?

Say I have the following in a .coffee file in shared/:

Colin = exports
Colin.VERSION = '0.0.1'

This will get compiled to:

var Colin;
if (!SS.shared.Colin) {
    SS.shared.Colin = {};
}
Colin = exports;
Colin.VERSION = '0.0.1';

But if I have this:

exports.VERSION = '0.0.1'

It gets compiled correctly, as

SS.shared.Colin.VERSION = '0.0.1';

Would it be possible to include usage of the exports variable as in the first example?

Help setting up routes in HTTP config

I'm having trouble figuring out the best way to set up routes in the HTTP config without having to write my own router.

I normally use Connect for setting up my routes, like this: http://senchalabs.github.com/connect/middleware-router.html

Most node routers are initialized by either passing the web server object in to the router, or passing the routing function in when you create the server. However, within the HTTP config you don't have access to the server object, only the request, response, and next callbacks. What's the best way to do this?

Textual replacement of exports.blabla in client code doesn't scale

This code

var foo = function ()
{
    var exports = {}
    exports.bar = function () {}
    return exports
}

alert(foo().bar)

when put to /client/foo.js, translates to:

if (typeof(SS.client.foo) == 'undefined') SS.client.foo = {};
var foo = function ()
{
    var exports = {}
    SS.client.foo.bar = function () {}
    return exports
}
alert(foo().bar)

and starts unexpectedly printing undefined instead of [Function].

Proper modules as per #69 or similar approaches will fix such bugs easily without a need to implement a full ECMAScript parser.

exports.authenticate = true doesn´t seem to work

in app/server/distributors.coffee
first line:
exports.authenticate = true

exports.actions =
distributors_all: (cb) ->
... do stuff here

i can execute this client side without any check for a logged in user
SS.client.distributors.distributors_all()

I´m using the custom_auth example and have no user logging in.

What am I missing?

Embed templates into main html on compilation

So that the index page is not cluttered with lots of template objects, we want a way to write template files, and have them compiled into a hidden div for efficient html transfer.

socketstream s seems compiles backup files

hi.

when I use vim, it creates backup files with a '~' at the end of them in the directory
when I try to start my app, it tries to load these, which results in the following error.

$ socketstream s
18 Jun 07:50:11 - Starting SocketStream server...

test/app/server/auth.coffee~:3
authorized: (params, cb) ->
^

node.js:134
throw e; // process.nextTick error, or 'error' event on first tick
^
SyntaxError: Unexpected token :
at Module._compile (module.js:402:25)
at Object..js (module.js:413:10)
at Module.load (module.js:339:31)
at Function._load (module.js:298:12)
at require (module.js:351:19)
at /usr/local/lib/node_modules/socketstream/lib/main.coffee:153:17
at /usr/local/lib/node_modules/socketstream/lib/main.coffee:172:11
at Array.forEach (native)
at Object.loadApiTree (/usr/local/lib/node_modules/socketstream/lib/main.coffee:167:27)
at Object.serverSideFiles (/usr/local/lib/node_modules/socketstream/lib/main.coffee:127:12)

On Cloud9IDE: Assets load path based on working directory instead of SS.root

In a non-standard run environment (Cloud9IDE). I have a bootstrap file as such:

require("coffee-script");

ss = require("socketstream/lib/main");
ss.init();

# Adjust SS.root to a subdirectory instead of the root dir
SS.root = SS.root + "/appname";

ss.start.server();

I have had to modify the line in assets/index.coffee where the public_path is set from exports.public_path = './public/assets' to exports.public_path = SS.root + '/public/assets' as well as making similar changes to the watch_dirs to make them based on SS.root instead of the current working directory.

Is this something that you would consider integrating into master?

.socketstream_state should be .socketstream_version

The "state" word is misleading - I thought the file was used for session store or something like that.

.socketstream_requirements is long but it would be fine too.

.required_versions is too vague but more general and thus futureproof

What do you think?

Ability to include 'password' in Redis configuration

Basically if the password property in the configuration object is set, call R.auth(password) before doing any other work.

Might make sense to include Augment.js

Augment.js provides implementations for any JS 1.8.5 (latest ver) methods missing from the current browser. In particular, I was surprised that Safari 5.0.4 does not have Function.prototype.bind. Making latest standard functions available everywhere seems to fit the vision of SocketStream.

Might want to only include functions missing from some of supported browsers.

http://augmentjs.com/

Directories more then one level deep under app/views cause "Error: EISDIR, Is a directory"

When creating views under the app/views folder, first level directories work ok. Creating nested directories fails with the error "Error: EISDIR, Is a directory"

Not a show stopper.

Monitor changes to files as well as inclusion of new files in the directory

pnotify, inotify

Auth'd session restored after page refresh

The logout feature in socketstream isn't working quite how I was expecting.

Relevant code:

lib/server/auth.coffee

exports.authenticate = (params, cb) ->
  if params.username == "test" and params.password == "password"
    cb({success: true, user_id: 123, info: {username: "test"}})
  else
    cb({success: false, info: {num_retries: 2}})

app/server/app.coffee

authenticate: (params, cb) ->
  @getSession (session) ->
    session.authenticate "auth", params, (response) =>
      session.setUserId(response.user_id) if response.success
      cb(response)

logout: (cb) ->
  @getSession (session) ->
    session.user.logout(cb)

loggedIn: (cb) ->
  @getSession (session) ->
    cb(session.user.loggedIn())

app/views/app.jade

a#logout(href="#") logout

app/client/app.coffee

$("#logout").click ->
  SS.server.app.logout (params) ->
    alert("you have logged out")
  false

First, I successfully login. The loggedIn server function returns true. Then when I click the logout link, I get the alert that says "you have logged out". At this point the loggedIn function returns false (as expected). However, when I refresh the page, the loggedIn function now returns true. I haven't looked at the socketstream code yet to find out what's going on, but it feels like the session cookie isn't getting updated/removed whenever I call session.user.logout.

Is this the expected behavior or a bug? Or is there something wrong in my code?

Thanks!

application-specific initialization data are sent too late

Currently, there's no built-in server action called when a socket connects. The init action has to be initiated by a client so some round-trip time is wasted.

Current situation:

1. A client connects
2. process.socket.connection hook is executed in socketstream/lib/server.coffee
3. client.system 'init' is called and certain system data are sent to the client
4. client receives init
5. client sends another init back
6. server receives init
7. server sends some application-specific initialization data to the client
8. client receives application-specific initialization data

Current situation is suboptimal, especially if you are targeting low-latency startup.

I propose either to allow sending application-specific initialization data in client.system 'init' or to allow hooking socket.on('connection') event in server-side app.coffee and sending from that place along with init.

The situation is identical on the client - it must have an ability to send some data (e.g. a locally generated security nonce) as early as possible.