Re: Update mechanism for standalone app/ Delta Updates

Hello Bastian,

thanks for your efforts with solving this problem.

I discoverd the "recipies" concept right after my first post. It took me 
a while to fully understand what it does and how to use. First i thought 
it could be a quick workaround to have kind of delta updates. Funny I 
had exactly the same idea as you suggested it. So i was hoping that ZI 
could somehow find the "<archive href=".../myapp-v1.zip"/>" in the cache 
from the previous implementation/version. After severall trials and 
errors i realized that this of course cannont work that way because 
there is no relation to an implementation id. ;(

But your idea, adding a new step type to the recipie section could be 
THE solution!

@Thomas
Is that feature possible at all?

In the meantime i'll evaluate if it's possible to split my app in 
modules. I let you know if that worked for me.


BTW, some thoughts about the future of ZI:

In my opinion ZI could experience a great upturn if it would support 
delta updates. Let me tell you why.
There is an always growing comunity which want's to create cross 
platform desktop apps. As far as i can tell the current biggest 
competitors are node webkit (http://nwjs.io) and electron 
(http://electron.atom.io/). Both frameworks enable you to write cross 
platform desktop apps on the base of plain HTML/CSS/Javascript and give 
you furthermore access to the endless eccosystem of node.js libs 
(https://www.npmjs.com/) . With these frameworks almost every "ordinary" 
Webdeveloper is now able to write "native" desktop apps which was long 
time reserved to "real developers". Having that said an app developer 
still has to decide which framework fit's best to its needs. There is a 
nice blogpost which compares nwjs and elctron 
(http://tangiblejs.com/posts/nw-js-and-electron-compared-2016-edition). 
It can be helpfull for decision making. From the feature point of view  
nwjs is the clear winner. But there is one important but missing feature 
in nwjs: an update mechanism.
I don't understand why it's still not implemented. There is an github 
issue from 2012(!) which targets this problem 
(https://github.com/nwjs/nw.js/issues/233). The topic is still actively 
discussed and many people posted their workarounds. I've tried allmost 
all of them and also did my own but none of the solutions is bulletprof 
neither secure.
On the other hand there is electron. If one negates the indicated 
disadvantages from the comparison (s.a.), we could have an auto update 
feature out of the box. Electron achives this by using Squirrel 
(https://github.com/Squirrel). The squirrel update framework also 
supports delta updates. BUT: in order to use the update feature, 
electron apps must be packed as windows installer. You see? Most of the 
desktop tools i develop have to be able to run on access restricted 
windows machines where user cannot install new software. This is by teh 
way also the main reason why i use nwj: You simply download the prebuild 
binaries and start the nwjs.exe with your app folder as an argument. 
Boom, you app starts. It's portbale, it's cross platform, it's easy to 
maintain - it's almost perfect.
When i saw ZI the first time i was sure that it could circumvent the 
update issue and many more problems. The possibility of ZI depoyed apps, 
to depend on other tools solves the problem, that we have to ship the 
prebuild binaries with each app (/update). HTML5 app have a small 
footprint by nature whereas the prebuild nwjs binaries can make up to 
100mb (packed). With ZI deployments can be much quicker  ( ... and save 
the world;)

As you can see i'am very enthusiastic about ZI and i willing to make it 
known to the node webkit community. Unfortunately, i can only contribute 
ideas from the user perspective couse i'm not able to code OCaml.

So kep it up!

Best regards

Jan





Am 22.02.17 um 09:35 schrieb Bastian Eicher:
>
> Hi Jan,
>
> you are right, applications built on cross-platform environments like 
> Webkit or Java are great candidates for Zero Install. Perhaps you can 
> help spread the word. :)
>
> The easiest way to get smaller updates with Zero Install right now is 
> to split your applications into multiple smaller components that can 
> be updated independently. However, this would require your application 
> to find the different “parts” of itself using environment variables. 
> For example your main feed might reference a MyApp-Videos.xml feed 
> like this:
>
> <requires interface=".../MyApp-Videos.xml">
>
>   <environment name="MYAPP_VIDEOS" insert="."/>
>
> </requires>
>
> Your app would then need to look in $MYAPP_VIDEOS instead of 
> ./app/media/videos. I have no experience with Node Webkit so I do not 
> know whether this would be easy to accomplish.
>
> Zero Install also has the concept of “recipes” that allow 
> implementations to combine multiple archives or other steps like 
> renames or removals. For example:
>
> <implementation version="1" id="sha256=abc">
>
>   <archive href=".../myapp-v1.zip"/>
>
> </implementation>
>
> <implementation version="2" id="sha256=xyz">
>
>   <recipe>
>
>     <archive href=".../myapp-v1.zip"/>
>
> <archive href=".../myapp-v2-delta.zip"/>
>
> </recipe>
>
> </implementation>
>
> However, this would only save you from having to upload large updates. 
> When downloading v2 Zero Install would still need to re-download v1 as 
> well because it does not know that the existing sha256=abc 
> implementation corresponds to the myapp-v1.zip archive recipe step.
>
> @Thomas: Perhaps we could introduce a new recipe step to handle this, 
> for example:
>
> <recipe>
>
> <implementation id="sha256=abc"/>
>
> <archive href=".../myapp-v2-delta.zip"/>
>
> </recipe>
>
> What do you think?
>
> Regards
>
> Bastian
>
> *From:*Jan Viehweger [mailto:[email protected]]
> *Sent:* Montag, 20. Februar 2017 11:52
> *To:* The Zero Install system <[email protected]>
> *Subject:* [Zero-install-devel] Update mechanism for standalone app/ 
> Delta Updates
>
> Hello list,
>
> i'm developing a cross plattform standalone app which need's an 
> (auto/self-) update mechanism. The app is written in HTML5 & node.js 
> and runs on Node Webkit (http://nwjs.io). The problem is: Node Webkit 
> does not provide an update feature.
>
> So i met zero install ;) . The concept behind blow my mind away and 
> i'm wondering why it's still quite unknown (in my scope)?
>
> I'm evaluating if ZI can solve my update problem 100%. So let me 
> explain in detail.
>
> One major requirement of the update routine is, that updates shout be 
> as small as possible. For that purpose other tools use so called delta 
> updates. I've already read delta updates are a upcomming feature for 
> ZI so i asked myself if i could use a workaround:
>
> The app itself consists of a small amount of javascript but a large 
> (and growing) number of mediafiles (images and videos). Updates will 
> most of the time consist of changed or new mediafiles. so creating 
> patches (delta updtes) for images or videos (where almost every pixel 
> changes) make no sense at all.
>
> So my idea is the following pragmatic idea:
>
>   * The deployed app will be versioned in a LFS
>     (https://git-lfs.github.com/) enabled GIT repo.
>   * Each change to the repo will be flaged as a new Version.
>   * The Diff between the last version and the current will be exported
>     as a zip containing only the modified and new files
>   * Transfered to ZI the idea is, that each version represents an
>     seperate feed/interface which depends on the previous versions
>     which by itself is an feed/interface too
>   * By this a tree of dependencies from one to the higher version will
>     be resoved.
>
> The big question now is, how to merge the files (each extracted 
> archive) together in one place and override older files with newer ones?
>
> For making it more descriptive, the following filestructure makes the 
> whole standalone app
>
>   * nwjs (DIR)
>       o nwjs.exe
>       o ...
>   * app (DIR)
>       o js (DIR)
>           + main.js
>           + ...
>       o templates
>           + view1.html
>           + view2.html
>       o media (DIR)
>           + videos (DIR)
>               # movie1.mp4
>               # movie2.mp4
>               # ...
>           + images
>               # image1.jpg
>               # image2.jpg
>               # ...
>
> The "nwjs" folder represents the Node Webkit runtime which itself 
> won't be touched. Normaly you just download it.
>
> The "app" folder contains the app to be run in Node Webkit. The app 
> will be started by calling the nwjs.exe withe the "app" directory as 
> the argument.
>
> The app interface/feed will be run by the Node Webkit interface.
>
> --------
>
> Any suggestions are welcome
>
> Best regards
> Jan
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Zero-install-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/zero-install-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
Zero-install-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zero-install-devel