Offline usage

[pfelecan]

There is a real need for an off line version.
I know that this was already discussed but there is no clear resolution.
I've seen the @pistolleror 's project but it doesn't seem to be maintained, the last activity was more than a year ago.
I understood that there is a great amount of work to document the procedure to obtain an off line version. However, I'm willing to help by applying your directions and to document them.
Let me know

[chilipeppr]

Hi Peter, I know there's always been a desire by some folks for offline, but I think lately more and more folks have gotten comfortable with this being online. Keep in mind once you've loaded the app in your browser, you can be disconnected from the Internet. Although the moment you open a dynamic widget like Eagle BRD you have to be online for it to download it.

…

On Thu, Dec 29, 2016 at 7:38 AM, Peter Felecan ***@***.***> wrote: There is a real need for an off line version. I know that this was already discussed but there is no clear resolution. I've seen the @pistolleror 's project but it doesn't seem to be maintained, the last activity was more than a year ago. I understood that there is a great amount of work to document the procedure to obtain an off line version. However, I'm willing to help by applying your directions and to document them. Let me know — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#42>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidbbUD6B3mrX9QXSXuB-z4pYs5s5Krks5rM9P_gaJpZM4LXqQc> .

[pfelecan]

So, if everything is loaded how can we save it and configure a local store for it?
I'm a software engineer and I can understand even though not so fluent in JavaScript.
If you explain the general lines of how to proceed I can try it and document.

[chilipeppr]

What's difficult about it is that ChiliPeppr is made up of about 30 Github projects that all come together only when you load the app. Now, in the final app all HTML, CSS, and Javascript is brought inline to one massive file in the DOM. That would seem things would then be easy because all you do is download that final monolithic file, store it locally, and you're done. However, there are the following things that get tougher: 1) Some widgets load dynamically when you open the widget, so that you don't get too much Javascript executing on load and sitting in memory. The Eagle BRD widget is a good example. Thus you have to grab that code dynamically too and when the Javascript requests the URL, you need to serve it locally. 2) Some widgets reference your online storage at ChiliPeppr. Not many do this, but for example, the TinyG Configure widget uses cloud storage. The serial port on load config widget uses this to bring up your cloud storage of settings. The JSCut widget loads cloud storage too for showing you what files you sent it from JSCut. 3) ChiliPeppr is constantly evolving, so to keep rebuilding the offline version on-the-fly would seemingly be important. Other than that, it's somewhat straightforward. -John

…

On Thu, Dec 29, 2016 at 2:00 PM, Peter Felecan ***@***.***> wrote: So, if everything is loaded how can we save it and configure a local store for it? I'm a software engineer and I can understand even though not so fluent in JavaScript. If you explain the general lines of how to proceed I can try it and document. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidbb2khz85p4oFSJA6mtlXi5y1vYafks5rNC1qgaJpZM4LXqQc> .

[pfelecan]

Thank you for this explanation.

If I'm well understanding there are 2 possible approaches: the first one being a black-box approach, what @pistolero have done, and a second one which is to have an explicit list of dependencies, i.e. projects, like a package, viz. Debian, with an neutral aggregation.

The black-box approach needs instrumentation to obtain all the needed components dynamically; it's difficult, error prone and with each change in the dependencies it must be rebuilt by using the specialized instrumentation; another inconvenient is that it;s not accessible to a lot of people and eventually has the same fate as the above cited project.

The package approach is not easy either but manageable and have the massive advantage of being a good candidate for packaging systems which gives a larger spread for the product.

If we agree that the second approach is the robust and manageable one, lets start to lay the Ariadne thread and start by the root of the dependencies graph and its direct descendants. Can you tell me which are those?

Later we will add the next level and so forth until we have established the total graph. When we have that I can build a set of Debian packages, for those missing from the current repository, as an example and immediate utility.

Thank you again for taking the time for this.

[chilipeppr]

Well, one place you could start is just writing a new widget, following the current widget model that is shown in the 3 videos on the homepage of chilipeppr.com towards the bottom. That widget could be called the "Offline Packager" and it would just walk the DOM that's currently loaded. It would then just build the massive monolithic HTML page with CSS and Javascript inlined. Then just let folks download the HTML page to their computer and run it in their browser. The other thing you'd need to deal with though is people can't run this from a file:// url because they need a websocket to the Serial Port JSON Server. So, you'd have to let them easily run it from a web server. Not sure how you'd best approach, but maybe a node.js express server. If you go the node.js route, then you could alternately just create a node project that people npm checkout. That node project would essentially download the chilipeppr.com/tinyg url, or whatever workspace you want, and then it would parse and pull in all dependencies. This feels like a worse way to go though because you're doing a ton of your own parsing rather than letting the browser do it like the first idea. Not sure best approach. Maybe broader question might be--is it worth it? How often do you not have Internet vs the amount of work?

…

On Fri, Dec 30, 2016 at 12:34 AM, Peter Felecan ***@***.***> wrote: Thank you for this explanation. If I'm well understanding there are 2 possible approaches: the first one being a black-box approach, what @pistolero <https://github.com/pistolero> have done, and a second one which is to have an explicit list of dependencies, i.e. projects, like a package, viz. Debian, with an neutral aggregation. The black-box approach needs instrumentation to obtain all the needed components dynamically; it's difficult, error prone and with each change in the dependencies it must be rebuilt by using the specialized instrumentation; another inconvenient is that it;s not accessible to a lot of people and eventually has the same fate as the above cited project. The package approach is not easy either but manageable and have the massive advantage of being a good candidate for packaging systems which gives a larger spread for the product. If we agree that the second approach is the robust and manageable one, lets start to lay the Ariadne thread and start by the root of the dependencies graph and its direct descendants. Can you tell me which are those? Later we will add the next level and so forth until we have established the total graph. When we have that I can build a set of Debian packages, for those missing from the current repository, as an example and immediate utility. Thank you again for taking the time for this. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidbS8fODts-wMQUzvN4aDjfz6_PKPSks5rNMIrgaJpZM4LXqQc> .

[pfelecan]

It's well understood that it should be served through a web server. There are a lot of alternatives, some light others heavy, for this purpose. Consequently, this is not an issue. IMHO, in an ideal world the HTTP server should be an user choice but we can offer the most popular / frequent.

What you're proposing by writing a new widget is the black-box approach which IMHO is clumsy and error prone. However, I'll explore it and come back.

In the meantime why not start to tell me which is the root of the project and the first level dependencies?

[chilipeppr]

Just go look at the DOM after you load any workspace and you'll see it's all documented inside it. Make sure to watch the 3 videos on the homepage too.

…

On Fri, Dec 30, 2016 at 5:50 AM, Peter Felecan ***@***.***> wrote: It's well understood that it should be served through a web server. There are a lot of alternatives, some light others heavy, for this purpose. Consequently, this is not an issue. IMHO, in an ideal world the HTTP server should be an user choice but we can offer the most popular / frequent. What you're proposing by writing a new widget is the black-box approach which IMHO is clumsy and error prone. However, I'll explore it and come back. In the meantime why not start to tell me which is the root of the project and the first level dependencies? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidbXrCYiCuCZd9qVzRlVerxFou2eb9ks5rNQwMgaJpZM4LXqQc> .

[pfelecan]

I've seen the 3 videos. In what concerns my issue, the first one is the most relevant as I'm interested in a workspace more than in a widget.

As an old school computer science professional I'm impressed by the software development paradigm that it demonstrates.

I'll explore the DOM of the TinyG workspace which motivates me in the beginning and let you know what I found out / understood.

Thank you again for your attention.