Happy Fun Times: A similar yet nitch application

[formula1]

https://github.com/greggman/HappyFunTimes

This framework and ours are very similar

• Both have applications the user can install and remove (https://github.com/greggman/HappyFunTimes/blob/master/lib/games.js)
• applications can be run as they please (though he only allows one at a time)
• Both allow applications to be run on server and client
• both have a custom json aspect (his is gameinfo.json ours is info.json)

Some things he did well

• He launches a browser on startup - We would have to do something similar except with fallbacks. first check if its NodeOS, if it is, we need to boot a chrome version that outputs directly to the framebuffer. next check if theres a boot to shell option. This would either be something like atom-shell, node-webkit or something else. Then we would boot to browser. That being said, the only thing reliable and easy right now is the browser form.
• Simple Method to look for a local server - All you have to do is go to that site and it finds a local server. Here is his current version minified and a version I wrote that is much easier to read. It requires Async through bower though. This is useful when the app is a server of some kind that would be used and viewed over the local network.
• He has made the applications installable on windows http://superhappyfuntimes.net/install
• he takes advantage of the fact you can connect to the server. This is pretty awesome from the context of "the internet of things". This can be applied to lights in your house, tv remotes and anything that you can create a server with and want to control it with your phone. Obviously he chose to go down the path of games (Which I don't blame him because making games is freaking awesome.).

Some issues with his framework

• On clientside, you are forced to work within his environment. Its not terrible since its mostly AMD aspects and giving the developer generic objects to work with. But since we are more free, this is a downfall
• Almost everything is custom code/not abstract - Its a bit frustrating walking through his code. Some of which seems purposefully hidden.
• No webRTC - I was initially going to try and fix this, but his code is a bit frustrating to deal with
• no GamePad API support - This is not Silks issue, however it definitely opens up some important questions.

Some Differences

• he has a json file the individual games and allows the file to stay in the same directory. This can be both a good and bad thing (https://github.com/greggman/HappyFunTimes/blob/master/cli/cmds/add.js). Good because it allows the game to do whatever it pleases. Bad because it reduces automation.
• Some of the information is within the package.json which also may be more reliable since we can use npm rather than use

PS: I'm still paying attention to this project. And Want to get back into it, but I also want to make sure we have a stun server that isn't google.

[zodern]

I am surprised how similar Happy Fun Times is to Silk. It has a cool idea.

Opening browser

When on platforms other than NodeOS, I have thought of using open.

Installer

NodeOS users will probably know how to install an application from the command line. I doubt there will be many people using Silk on Windows or Mac, but if there ever is an installer might be a good idea.

This is pretty awesome from the context of "the internet of things". This can be applied to lights in your house, tv remotes and anything that you can create a server with and want to control it with your phone.

That has a lot of potential. Apps have enough freedom they could do this themselves. Should Silk do anything to help apps with this? I am going to make some changes to remote to work with apps that use a different port. I also will add methods to the server api so apps can control remote.

[zodern]

I'm still paying attention to this project. And Want to get back into it, but I also want to make sure we have a stun server that isn't google.

Great! I have learned a lot from you.

[formula1]

open

That is an excellent library

The installer

I agree, its probably not necessary. But its food for thought to say the least

Internet of things

I 100% agree with you that this should and can be done on an app level. To make it easier, there is this script to find on wifi. Finding on bluetooth may be more complicated but still possible via (https://github.com/eelcocramer/node-bluetooth-serial-port)

Something related though completely seperate

I don't know if you know this or not but processes can send sockets and servers to eachother. This can be done over child process and thanks to @VanCoding between completely unrelated processes. The second one I have no idea what to use it for but I think its really cool. It could be used as a load balancer or better allow apps to connect to silk without silk having to start it. This may result in confilcts though and/or dangerous applications, but its available.

What this allows us to do is give all of our apps the sockets that are directed to them.

• We have access to the original request - https://github.com/einaros/ws/blob/master/doc/ws.md
• We read the request path via - url.parse(ws.originalReq.url).path
• We can check which app the websocket should be sent to apps[path.split("/")[0]]
• We send it to them apps[path].fork.send("websocket", socket)

This would be good for a few reasons

• We no longer need to relay messages from the applications fork to the server
• The server doesn't have to listen to sockets that aren't related to them within its loop

WebSockets are actually just tcp sockets, however ws creates a wrapper around it to make it easier to use. Unfortunately, we cannot send Objects, only sockets. I ran into a lot of frustration trying to make sure the websockets can be exported and imported, which in part relates to me being inactive temporarilly until I could get that togethor. We can also bypass ws in some ways by creating a tcp server that we then manually call server.handleUpgrade to construct the ws.WebSocket within each child process. But that then requires every child process to require ws which may not be the best idea.

Trust me when I say I'm still actively thinking about Silk. Theres just a lot of code I've written that will never see the light of day : /. I just need a break from IO for a bit. I've been trying to translate code from one language to another, getting deep into other peoples code to see what I can do to scrap parts and learning new programming environments and its definitely tiring.

Thanks for letting me know you've learned from me. I'm certianly not @netlovers or @piranna but its cool I can share whatever tricks I can with you :)

[zodern]

I agree the web socket should be sent to the app. Methods could remain in the app, and there could be public methods any app could call (such as app defaults).

In the dev branch I am trying sockjs. Web sockets didn't work with localtunnel and sockjs is able to emulate them. The connection instance it says supports Node Stream API, so I don't know if that means it is a stream or has a similar api. It has a property for the url and pathname.

[formula1]

Here are possible issues

• ws.id doesn't exist - https://github.com/Silk-GUI/Silk/blob/dev/core/fork_framework/ws2fork_com.js#L82
• Your providing a url so that it can be cross domain but may not be implementing it on the browser (see sockjs_url) - https://github.com/sockjs/sockjs-node/#server-class
• You aren't hooking it into an actual http server - example code/our code

Wasn't a fan of my tunnel implementation? ;)

By the way, sockjs seems awesome. this is its dependency. And that's dependency is even better!

its api allows for the socket to still be a seperate aspect. This will allow the socket to be passed to child processes without (much) issue! There may be conflicts with handshaking, so it most likely cannot be created more than once. However, the request is an http request allowing us to see, parse and direct the request to the right location without creating it. Ah, give me some time and I'll get back into this. I'm getting all excited

[zodern]

Thank you for pointing those issues out. I will try to fix them.

Wasn't a fan of my tunnel implementation? ;)

I plan to use it. I am not using it yet because it needs to be on a server. Would it work on a free dynamo on Heroku?

[formula1]

It should work on heroku. Though It seems that with heroku you pay by hour unless I'm mistaken. That will most likely end up at about $30 a month. If your looking for free, sockjs probably has your back on that.

[zodern]

Heroku gives one dyno for free. https://www.heroku.com/pricing.

Microsoft azure gives 10 websites and 5 gb bandwith for free.

I will keep localtunnel for now, but once Silk gets some users I will switch to your tunnel. Something like remote.silk.io would be better than subdomain.localtunnel.me and the password protection in your tunnel will be nice.

[zodern]

In the dev branch, you can now open a nw.js window with the --open flag. Added in 616a7df60b5b985d0edcefbe6c08a0ab239059b3

[formula1]

oooooo Thats sweet!