Offline usage #42
Comments
|
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>
.
|
|
So, if everything is loaded how can we save it and configure a local store for it? |
|
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>
.
|
|
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. |
|
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>
.
|
|
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? |
|
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>
.
|
|
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. |
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
The text was updated successfully, but these errors were encountered: