"App" deployment format.

[ryansturmer]

So I think we've settled on the idea of an "app" being a packaged bundle which gets hosted (either on the tool or on the client machine) Here is a short list of properties of an "app"

1. Apps are just bundles of html/js/css/data that are "run" by loading in a web browser
2. App bundles are a single file, (such as a ZIP)
3. App bundles contain some kind of manifest that identifies their contents. The manifest might contain some of the following:
   • Title
   • Author
   • Website
   • GUID/Hash
   • App Version
   • API Version
   • Index File?
   • Online dependency? (Some indication as to whether the app needs to "phone home" to access its functionality.
4. App bundles might get to assume offline access to certain dependencies, either by pulling them from the tool, or by having access to them when hosted on the client's computer/phone/etc. Examples of these sorts of dependencies include CSS/JS libraries like JQuery, D3, Bootstrap, but might also include fixed 'look and feel' assets such as logos, buttons etc.
5. Apps use the link API (localhost) and the tool API (the tool) to perform tool functions
6. Apps that are hosted from the tool should be able to know they're hosted on a tool

So, questions are:

1. How do we bundle? ZIP, GZIP, Base64 encode a bunch of data all in a single HTML/JS file?
2. What data gets included in the manifest?
3. Is the app an HTML file that is visited wholesale? Or is it meant to be included in a template or iframe through some sort of dynamic loading process? The former is simpler, but the latter might provide more flexibility and polish.
4. Is there a size limit to apps?
5. Do we do the fixed asset thing, or not bother with it, and require that dependencies be included in the app (having app authors include a minified jquery, bootstrap, d3, etc isn't really a big deal, certainly, unless you're offended by duplicating all that data... I'm not.)

Just kicking off the discussion here.

[ryansturmer]

Alan mentioned the app being sort of the front end of an interface that would then kick you into a utility that provides the management functionality for the tool. Since the apps are essentially just producing g-code in most cases, it would make sense to extract the activities of running the g-code, monitoring progress, providing pause/resume functionality, etc. and keeping them standardized across all app instances.

[AlanCramer]

So ... Jeanne's team and I have been using the word App in a different context. We are imaging a website for ourselves and others to provide tools for generating G-Code. In particular, we're building a new way for people to describe 3D geometry (well technically, 2.5D geom) with a greyscale image. These apps will live on a website in the handibot domain.

The functionality of these apps today goes up to the point of generating some GCode. How this GCode gets loaded, verified or run on the Handibot is not clear to me.

Because these apps currently stop at generating GCode, they can, and hopefully will be used for a broader spectrum of tools, including all the Shopbot tools, but maybe also laser cutters etc.

[jlucidar]

Hey Alan, I made your app run locally and directly send a gcode file to the tool for execution. It uses the new version of the makermo.js library, and there are very few changes in your code files (less than 10 lines) see it there

[tedh-shopbot]

PULLING TOGETHER A FEW THINGS ...

Getting a useful set of words to describe things is difficult ... in the SDK intro that I am developing for public consumption, I have left things pretty vague. But I reproduce here how I think the major labeling should go.

We are working across many levels to create a general “Digital Fabrication Innovation and Control Platform” … that might be abbreviated as “FabCo” ...

Within our system, in addition to Apps our “FabCo platform” has:

• a “Linker” that identifies and pairs user devices with digital fab tools over various communications options, the Linker runs runs locally on user device, and exposes basic functions to developers – FabCo Linker
• an “API” available to developers for doing all of the overarching management work; the API represents functionality that is primarily based in software on the tool's SBC – FabCo API
• and a low-level, uC-embedded motion system “Core” made up of G2 components – FabCo Core

Here, I am going to re-write the first part Ryan's earlier summary slightly, to fit this scheme:

[tedh-shopbot]

FROM RYAN.............

Alan mentioned the app being sort of the front end of an interface that would then kick you into a utility that provides the management functionality for the tool. Since the apps are essentially just producing g-code in most cases, it would make sense to extract the activities of running the g-code, monitoring progress, providing pause/resume functionality, etc. and keeping them standardized across all app instances.

There are a couple of issues here. It seems to me that all App developers (local or web; Utility or Project & Design) will be making decisions about how much "management" they want to expose. The necessary data and function calls are available to the developer in the FabCo API (or in an abstraction of it, as per Jimmy's current "makermo" that gives developers even simpler tools for working with the API). BUT, there is a certain level of functionality that is inherent in FabCo software and G2 (and as is represented by the FabCo API concept). That functionality is for such things as Stopping/Resuming. We have not worked through this one yet, but I can imagine a system where this is entirely handled on the tool (G2<>FabCo-SBC-software) and optionally in the App (depending on whether the developer is exposing and handling monitoring; for which I guess we would we need to build in a simple dialogue). We will have this same issue need for a couple other housekeeping tasks.

[ryansturmer]

Yes, I agree, there is a continuum of developers from people who just want a "print" button to people who are interested in doing more interesting things by controlling the tool directly. The latter folks are sort of satisfied automatically, because the low-level control of the tool is what we're developing first. The first example "apps" that we're working on will send files direct to the tool and it will be their responsibility to monitor feedback from the tool and present it to the user. As far as a tool management utility goes.... we're already working on that too. In short, I think in response to a continuum of developers with varying interests, we provide a continuum of options for connecting to the tool, placing priority on the very high level "print button" utility type interface. To that end, we already have a tool that is sort of a test-bed for the API that I think can be made to fit that bill nicely. It lives on the tool currently, and provides basic management of files on the tool, starting of files, etc:

I think the main questions are:

1) how much do we want to include in such a utility 2) where does it live 3) How do developers interact with it 4) Is the utility something that developers "include" in their app - or it something that lives as a "post" to the CAD/CAM process. 5) How do we standardize the way that developers avail themselves of this functionlality so that we can grow the tool without breaking apps

I will give my answers to these questions below, but this is all very exploratory, so I don't expect anything is definitive.

1) I think OctoPrint provides a pretty solid example of what such a tool would look like. It's clean, simple, and comprehensive. 2) My current thinking is it lives on the tool 3) In the simplest scenario, developers could just POST their file to a url that redirects them to the utility, with the file loaded and ready to go. 4) I think it's a separate "post" utility, but makermo.js or something similar could include a "lite" management console.... just a styled widget or dialog that would let you run the tool from within your app if you wanted that as an option. There are a lot of ways to do it. 5) Maybe the URLs for kicking into the management utilities are a part of the tool API

[jlucidar]

I think this question is solved for now. An app is composed of a "package.json" file where all the information about it are present. the user is free of including whatever he needs in his app (html files, js or css libraries) and organizes it as he wants. the bundled format is a zip file whit a changed extension (.fma) We can reopen it if we have more suggestion