stretchyboy
commented
13 years ago I've been thinking about this tonight and will try to send you a proposal tommorow.
Closed dethe closed 11 years ago
stretchyboy
commented
13 years ago I've been thinking about this tonight and will try to send you a proposal tommorow.
dethe
commented
13 years ago Sounds good, sorry to be slow on integrating your work. I've just been tied up with home stuff, and doing a bit of work towards a server component for Waterbear, and some docs.
stretchyboy
commented
13 years ago Don't worry about integrating too much, I expect that if we can make the code bases work nicely together then pull will work pretty cleanly.
I've been avoiding looking at my server end (I have to integrate an AVR complier into mine) but expect that we will need something with an api that the client talks to but we don't care what its written in and maybe have really seperate projects for the server as there won't be much crossover apart from the api.
One other thing I was wondering if it might be a good idea to hook this interface to a node.js server. (kids writing web pages / services graphicaly directly in js :)
On 31 May 2011 00:03, dethe < reply@reply.github.com>wrote:
Sounds good, sorry to be slow on integrating your work. I've just been tied up with home stuff, and doing a bit of work towards a server component for Waterbear, and some docs.
Reply to this email directly or view it on GitHub: https://github.com/dethe/waterbear/issues/7#comment_1264035
Regards,
Martyn Eggleton ACCESS SPACE Unit 1, AVEC Building 3-7 Sidney St Sheffield, S1 4RG, UK t: +44 (0) 114 249 5522 w: www.access-space.org
stretchyboy
commented
13 years ago I know that this is major looking plan but I need to work on sorting out the plugin / project structure next as it is limiting how closely we can work and I imagine making it harder for other lanuages to start. So whichever way you want to sort it out It will be my next job.
I think that the index.html in the main package should have a defaultmode var in it. I think if we use a modes directoy structure like below we could write code to parse the the index of modes directoy to give us a mode selection page with links to the other modes and use js to parse ?mode=arduino etc. to switch mode as well.
As you suggested we use __localstorage to store what someone was using.
We then use the modename with an obvious file structure to load mode.js which this has meta data about the mode and the yepnope array of the other resources needed for it
Yeah this is complex but should mean we can manage add modes at will. And means that if pull works like i think it does you can pull all the core changes without having to take the arduino files if you want.
dethe
commented
13 years ago I agree we need a server component (for many reasons), and I like Node.js a lot (and CouchDB for storage). One request I've gotten is to support output to the serial port for a teacher in Spain who is using Scratch now for teaching robotics. There seem to be four approaches to that: ActiveX, Flash (requires an additional component on top of Flash), Java (also requires an additional library to be installed), or run from a local server and use the server to talk to the serial port.
Another approach, similar to the server, would be to wrap Waterbear in an app using Fluid (for Webkit) or Chromeless[2](used to be Prism, for Firefox) and extending the app to expose serial communications to Javascript.
I mention this because Arduino code will have similar issues, I imagine.
[1] http://fluidapp.com/ [2] https://mozillalabs.com/chromeless/
dethe
commented
13 years ago I like this plan, and storing the last-used mode in LocalStorage is optional for now, just a way to maintain user prefs. One thing I think would be good is to allow modes to layer, which I haven't really been good about so far. So Raphael shouldn't really be the mode: Javascript should, with Raphael an imported/layered mode (hell, let's just call it a library, since that's what it is). So someone could start with Javascript and pull in Raphael, or Crafty, etc.
Each library should have access to make changes to the UI, just as the main mode should. And some libraries may remove or replace blocks from the main mode, so Underscore library may replace the Javascript loop block with an iterator, Arduino may remove some simple blocks that compose behaviour and replace them with the lower-level blocks used to build from, etc.
Does that sound reasonable, or am I over-thinking it?
stretchyboy
commented
13 years ago I hadn't actually seen your server project on github until after I wrote that semi joke comment. But node.js could be good as a back end for some situations and i do think that having it as a mode would be a great idea.
there is another option on the serial side you could use websockets to talk to the server (https://gist.github.com/754683) and something off this list http://en.wikipedia.org/wiki/COM_port_redirector#Open_source_solutions to make the link to the serial port on the desired machine.
The cromeless ideas are also worth a look.
On 31 May 2011 18:26, dethe < reply@reply.github.com>wrote:
I agree we need a server component (for many reasons), and I like Node.js a lot (and CouchDB for storage). One request I've gotten is to support output to the serial port for a teacher in Spain who is using Scratch now for teaching robotics. There seem to be four approaches to that: ActiveX, Flash (requires an additional component on top of Flash), Java (also requires an additional library to be installed), or run from a local server and use the server to talk to the serial port.
Another approach, similar to the server, would be to wrap Waterbear in an app using Fluid (for Webkit) or Chromeless (used to be Prism, for Firefox) and extending the app to expose serial communications to Javascript.
I mention this because Arduino code will have similar issues, I imagine.
Reply to this email directly or view it on GitHub: https://github.com/dethe/waterbear/issues/7#comment_1268634
Regards,
Martyn Eggleton ACCESS SPACE Unit 1, AVEC Building 3-7 Sidney St Sheffield, S1 4RG, UK t: +44 (0) 114 249 5522 w: www.access-space.org
dethe
commented
13 years ago Websockets to the remote server still doesn't help with serial access unless a) there is a connection from a local tool with serial access also to the server (kind of a huge security problem), or b) the serial port is also on the server (ditto). That's why I'm thinking of a local server or wrapping in an application (which is like a self-contained local server + client).
stretchyboy
commented
13 years ago The mode layering was what I was trying to get at with my arduino bit of that files structure. You would have a mode directory for each full interface you wanted to show but it could get bits it needed from other modes, I was going to split up your raphael stuff in my proposal but I didn't want to impose too much.
I was originally thinking that there wouldn't be any overloading just merging of the menus but I think that overwriting or removing whole menu sections is a better idea.
Basically we seem to be thinking along similar lines.What do you want to call them, I went for modes because in my case that is what they are, the intial ones at least will all write the same language without any external librairies but offer different modes of interaction. In your case we are wrapping different js libraries in UI so you could say you have a pure javascript mode which provides the simple stuff. and then a raphael mode that extends that to what you have at the moment.
That sounds very similar to your thought but is it close enough that we are clear?
On 31 May 2011 18:36, dethe < reply@reply.github.com>wrote:
I like this plan, and storing the last-used mode in LocalStorage is optional for now, just a way to maintain user prefs. One thing I think would be good is to allow modes to layer, which I haven't really been good about so far. So Raphael shouldn't really be the mode: Javascript should, with Raphael an imported/layered mode (hell, let's just call it a library, since that's what it is). So someone could start with Javascript and pull in Raphael, or Crafty, etc.
Each library should have access to make changes to the UI, just as the main mode should. And some libraries may remove or replace blocks from the main mode, so Underscore library may replace the Javascript loop block with an iterator, Arduino may remove some simple blocks that compose behaviour and replace them with the lower-level blocks used to build from, etc.
Does that sound reasonable, or am I over-thinking it?
Reply to this email directly or view it on GitHub: https://github.com/dethe/waterbear/issues/7#comment_1268705
Regards,
Martyn Eggleton ACCESS SPACE Unit 1, AVEC Building 3-7 Sidney St Sheffield, S1 4RG, UK t: +44 (0) 114 249 5522 w: www.access-space.org
stretchyboy
commented
13 years ago the second link ( http://en.wikipedia.org/wiki/COM_port_redirector#Open_source_solutions) is to a list of open source software that would allow that websocket to serial script to then talk to the serial ports on the computer that sent the request (yes that would only really be doable with the server in the class room but that is what i'm planning for my stuff)
On 31 May 2011 19:26, dethe < reply@reply.github.com>wrote:
Websockets to the remote server still doesn't help with serial access unless a) there is a connection from a local tool with serial access also to the server (kind of a huge security problem), or b) the serial port is also on the server (ditto). That's why I'm thinking of a local server or wrapping in an application (which is like a self-contained local server + client).
Reply to this email directly or view it on GitHub: https://github.com/dethe/waterbear/issues/7#comment_1269038
Regards,
Martyn Eggleton ACCESS SPACE Unit 1, AVEC Building 3-7 Sidney St Sheffield, S1 4RG, UK t: +44 (0) 114 249 5522 w: www.access-space.org
dethe
commented
13 years ago Your mode description sounds spot on. My only problem with calling them modes is that mode tends to imply exclusive, while we want them to layer and interact (in some cases). So I think each language could be a mode (Javascript, Arduino, etc.), but then the mode could pull in libraries.
Re: websockets. So for your case, the teacher would run a server and all students could send their scripts through that for compiling and/or serial access? That could work, but if multiple students were trying to control their robots simultaneously, they'd want to use their local serial devices. We could support both, but I'd like to pick one preferred solution to do first. I'm going to look at how hard it would be to integrate one of the serial libraries with Fluid. One further tool for wrapping webapps is Appcelerator Titanium [1], which is commercial, but does have the ability to communicate between Javascript in the client and Python on the host, so talking to the serial port (or compiling Arduino code) should be do-able.
stretchyboy
commented
13 years ago How do you feel about calling them plugins instead of libraries (maybe they could have types so you would have a language plugin called 'arduino' and a library plugin called 'raphael'. which would give us one extension mechanism which covers everything. Its how dokuwiki and various other things do it)
So you would say you wanted the javascript with the sketchy plugin, that would load the javascript (which would be kept as a plugin anyway) and then the sketchy plugin which would depend on the raphael. As the raphael would depend on the javascript you could just ask for sketchy and get all of it, or specify a language and plugins.
That would give the 'choose the one interface by name and get everything you need to make it work' model which is what I leaning towards and the 'pick a core language and the extra libraries you want at the moment time' model that you seem to be leaning towards (which if I think about it I will need later on as well)
On 31 May 2011 19:56, dethe < reply@reply.github.com>wrote:
Your mode description sounds spot on. My only problem with calling them modes is that mode tends to imply exclusive, while we want them to layer and interact (in some cases). So I think each language could be a mode (Javascript, Arduino, etc.), but then the mode could pull in libraries.
Re: websockets. So for your case, the teacher would run a server and all students could send their scripts through that for compiling and/or serial access? That could work, but if multiple students were trying to control their robots simultaneously, they'd want to use their local serial devices. We could support both, but I'd like to pick one preferred solution to do first. I'm going to look at how hard it would be to integrate one of the serial libraries with Fluid. One further tool for wrapping webapps is Appcelerator Titanium [1], which is commercial, but does have the ability to communicate between Javascript in the client and Python on the host, so talking to the serial port (or compiling Arduino code) should be do-able.
[1] http://developer.appcelerator.com/
Reply to this email directly or view it on GitHub: https://github.com/dethe/waterbear/issues/7#comment_1269293
Regards,
Martyn Eggleton ACCESS SPACE Unit 1, AVEC Building 3-7 Sidney St Sheffield, S1 4RG, UK t: +44 (0) 114 249 5522 w: www.access-space.org
stretchyboy
commented
13 years ago I wonder whether as you need the local serial you should look at that first. I will have to see whether that will allow me to do the complying that i need to do on the server and then use the local serial to get it on to the arduno but I reckon it will.
And then assuming we give the teacher access to all the scripts that have been put on the server it will be able to run a lesson with just 1 arduino or robot at the front if needed.
On 31 May 2011 20:20, Martyn Eggleton martyn.eggleton@gmail.com wrote:
How do you feel about calling them plugins instead of libraries (maybe they could have types so you would have a language plugin called 'arduino' and a library plugin called 'raphael'. which would give us one extension mechanism which covers everything. Its how dokuwiki and various other things do it)
So you would say you wanted the javascript with the sketchy plugin, that would load the javascript (which would be kept as a plugin anyway) and then the sketchy plugin which would depend on the raphael. As the raphael would depend on the javascript you could just ask for sketchy and get all of it, or specify a language and plugins.
That would give the 'choose the one interface by name and get everything you need to make it work' model which is what I leaning towards and the 'pick a core language and the extra libraries you want at the moment time' model that you seem to be leaning towards (which if I think about it I will need later on as well)
On 31 May 2011 19:56, dethe < reply@reply.github.com>wrote:
Your mode description sounds spot on. My only problem with calling them modes is that mode tends to imply exclusive, while we want them to layer and interact (in some cases). So I think each language could be a mode (Javascript, Arduino, etc.), but then the mode could pull in libraries.
Re: websockets. So for your case, the teacher would run a server and all students could send their scripts through that for compiling and/or serial access? That could work, but if multiple students were trying to control their robots simultaneously, they'd want to use their local serial devices. We could support both, but I'd like to pick one preferred solution to do first. I'm going to look at how hard it would be to integrate one of the serial libraries with Fluid. One further tool for wrapping webapps is Appcelerator Titanium [1], which is commercial, but does have the ability to communicate between Javascript in the client and Python on the host, so talking to the serial port (or compiling Arduino code) should be do-able.
[1] http://developer.appcelerator.com/
Reply to this email directly or view it on GitHub: https://github.com/dethe/waterbear/issues/7#comment_1269293
Regards,
Martyn
Martyn Eggleton ACCESS SPACE Unit 1, AVEC Building 3-7 Sidney St Sheffield, S1 4RG, UK t: +44 (0) 114 249 5522 w: www.access-space.org
Reg. Charity 1103837
Regards,
Martyn Eggleton ACCESS SPACE Unit 1, AVEC Building 3-7 Sidney St Sheffield, S1 4RG, UK t: +44 (0) 114 249 5522 w: www.access-space.org
dethe
commented
13 years ago I think plugins captures the idea well, and I agree it covers both the language and the libraries. Dependency management might get tricky, but if we make it all explicit it should be manageable.
dethe
commented
13 years ago If the local app can access serial ports, or local executables to compile Arduino code, then they can always expose that to others through websockets and a relay server, so the centralized case should fall out of it. The best reasons not to do it that way that I can see are if you really want all access to "risky" resources to go through a centralized point, for instance if you didn't want students to be able to write arbitrary code to the serial port (or if the machines were too locked down to allow it).
stretchyboy
commented
13 years ago just found this which might be of use.
https://github.com/voodootikigod/node-arduino
that is a library for the Node.js javascript webserver for talking to arduino.
if you could wrap it in an installer it and put it on all the machines then you could get serialport comms through localhost.
On 31 May 2011 22:31, dethe < reply@reply.github.com>wrote:
If the local app can access serial ports, or local executables to compile Arduino code, then they can always expose that to others through websockets and a relay server, so the centralized case should fall out of it. The best reasons not to do it that way that I can see are if you really want all access to "risky" resources to go through a centralized point, for instance if you didn't want students to be able to write arbitrary code to the serial port (or if the machines were too locked down to allow it).
Reply to this email directly or view it on GitHub: https://github.com/dethe/waterbear/issues/7#comment_1270381
Regards,
Martyn Eggleton ACCESS SPACE Unit 1, AVEC Building 3-7 Sidney St Sheffield, S1 4RG, UK t: +44 (0) 114 249 5522 w: www.access-space.org
dethe
commented
13 years ago Yes, the Node-Arduino bridge is cool. Installing Node into a waterbear package might be a bit heavyweight, though. I'm waiting to hear back from the author of Fluid about serial port access, and the Firefox version seems to be in the middle of a(nother) huge rewrite, so I've been focussing on Titanium, which can access Python or Ruby from the packaged webapp, and there is a pure-Python serial library, so I'll be testing that route.
dethe
commented
13 years ago Had an idea for supporting Arduino and serial port comms directly from the browser. Each platform (windows, linux, mac) has a way to register protocol handlers for things like http:, ftp:, telnet:, etc. An app can even register new protocol handlers and set itself as the default handler. The way this is done is different for different platforms, but not very difficult from what I can see. If we have a helper app that is downloaded and registers itself, we can bundle the script into one long arduino:longscriptoesheresuitably%20url%20encoded and send it magically on to the compiler/loader. Even easier than Titanium, perhaps.
What would be the appropriate destination to route the arduino script to? I have only used the Arduino IDE, but I assume compiling and loading can be controlled from the command line too?
stretchyboy
commented
13 years ago er.. arvdude is involved but I will need to look it up.
On 18 July 2011 05:12, dethe < reply@reply.github.com>wrote:
Had an idea for supporting Arduino and serial port comms directly from the browser. Each platform (windows, linux, mac) has a way to register protocol handlers for things like http:, ftp:, telnet:, etc. An app can even register new protocol handlers and set itself as the default handler. The way this is done is different for different platforms, but not very difficult from what I can see. If we have a helper app that is downloaded and registers itself, we can bundle the script into one long arduino:longscriptoesheresuitably%20url%20encoded and send it magically on to the compiler/loader. Even easier than Titanium, perhaps.
What would be the appropriate destination to route the arduino script to? I have only used the Arduino IDE, but I assume compiling and loading can be controlled from the command line too?
Reply to this email directly or view it on GitHub: https://github.com/dethe/waterbear/issues/7#issuecomment-1592758
Regards,
Martyn Eggleton ACCESS SPACE Unit 1, AVEC Building 3-7 Sidney St Sheffield, S1 4RG, UK t: +44 (0) 114 249 5522 w: www.access-space.org
dethe
commented
13 years ago I can look it up, just thought you might know. Does the general idea feel sound?
Further reading for registering protocol handlers:
http://www.cocoadev.com/index.pl?HowToRegisterURLHandler http://support.mozilla.com/en-US/kb/The%20protocol%20is%20not%20associated%20with%20any%20program http://kb.mozillazine.org/Register%5Fprotocol http://developer.apple.com/library/mac/#documentation/Carbon/Reference/LaunchServicesReference/Reference/reference.html
Most languages will not need to include things like Raphael. Introduce a loader so language files can include their own dependencies.
There are quite a number to choose from now (see http://microjs.com/#loader). YepNope is the one that will be integrated into Modernizr, let's try that and see if it is sufficient.