Is it possible for ICE to support local assets?

[eee-c]

It would be nice to support local images / textures / geometries. Can ICE help?

Can currently:

• Run ICE under a local web server that also includes assets
• Run chrome with --allow-file-access (untested)
• Upload assets to a publicly available web server

None of those are prohibitively difficult with web development experience, but beyond what can be expected of kids. Also, it would just be nice if ICE could make this easier...

[terrasea]

You could use Chromes FileSystem API, and store all these images, etc in
the browsers FileSystem. Not sure if that's easy for kids to use, but it's
worth investigating, I think. The caveat here is only Chrome supports the
FileSystem API.

[influx6]

Don't you will only limit yourself, look into using a db, or fast redis store, that can prereload the ‎images, a few get request won't hurt and you can have full support

[influx6]

In truth,you needn't expose much detail to the kids,use a keep alive websocket connection and grab the resources seamlessly without much fuss,they wouldn't know the difference, then store that data locally and update when changes occur,you can never avoid the need for connectivity and to be honest kids these days expect everything to be connected

[terrasea]

To be honest, I'm just wanting to avoid the need for a server instance to
serve these files. It would be nice to be able to serve them from a
server, but only if you're willing to pay for it, or set one up locally. I
realise using the filesystem api will limit things, but from what I gather,
the browser Chris recommends is Chrome anyway. Of coarse this doesn't
solve the sharing of files between a group of kids. Then maybe you're
referring to something else when you say we'll only limit things.

Another option is to write a simple server in Node.js, Dart or whatever,
have it produced as a downloadable file from the ice code editor, then
provide some simple instructions on how to run it.

I'm just throwing ideas out there, which maybe wild, but I hope it will
either get the brain cells going on a better solution or one of them will
be a good idea.

[influx6]

Well indeed I understand your dilemma ,lol, as to my statement about it being limiting I indeed only referred to the need for cross-browser functionality, but if chrome is the only desired browser then the internal fs should be used,no need to serve up from server but still there will need be, that the initial files must be downloaded along with ice or served up at the first load, which in itself is an idea,if it must be cross browser or even chrome only, and the clients are not required to synchronise update of the files or changes or addition of new textures and images,then just allow the initial download to come with ice or serve up ice with the files the first time it's loaded assuming it's through a weblink and it goes client only from then on,but if it's the other case then you will still need a central server and sync'ing multiple clients will need a local or remote server, you can tell them to pay for you to fix it up or provide a paid package 'ice special' that includes these features.

[influx6]

Oh my,since it's local assets, well you either provide a local server or provide a means for each client to connect to each other to be able to allow such . But as said connectivity is king these days having a remote server that serves assets shouldn't be an issue, in fact you can upload them to github as gists, and have ice grab a list of those with thumbnails and the user just grabs what they need

[terrasea]

We could look at turning it into a Chrome app, which gives it more
permissions, which may help with the sharing of assets, but I only know
enough about chrome apps to make me dangerous at the moment.

[JonKaye]

Going the Node route as terrasea suggested sounds interesting since it (a) can be run locally for offline operation, and (b) could help in solving the other issue recently added about sharing code -- if the instructor/coordinator had a live internet instance via the internet.

[influx6]

I agree with the node approach as well,the support is wide and definitely a good choice and wether it's on the Internet or using a internal network with routers,should still kickass with Ajax or websockets

[JonKaye]

I am a Node and Dart novice but advanced developer, I'd put time into helping out on this if someone wants to lead.

[eee-c]

@JonKaye Sign-up for a #pairwithme session! That's the best way to get started 😁

FWIW I'd still lean toward putting assets on a publicly available site with easy local replication like a Dropbox shared folder. I know that we can serve it locally with Node, but I'd only think that's a good option if it adds some kind of value to people.

[influx6]

It does add value, think of the massive share option and you can build a service like best ice build or a 3d gallery of awesome work, a means of gratification for the kids —Reply to this email directly or view it on GitHub.

[influx6]

                                                                                                                                                                                                                                                                      Also I wouldn't necessarily go local server, think of a more remote node server, where the local client keep track of commit tags/uuid, every gains access to the same share pack of user created content

[JonKaye]

great, thanks Chris, I have some big commitments this week but I'll sign up with you next week.

[terrasea]

I think there are JS APIs for accessing things like Dropbox and Google
Drive, which is all client side. Not sure that would help with including
assets in the code the kids write, but it might help with sharing code with
others.

[eee-c]

Merging this into #104