search

nagyistoce / update-engine

Automatically exported from code.google.com/p/update-engine
Apache License 2.0
0 stars 0 forks source link

Merge the project with omaha in order to provide multiplatform update service #17

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
This project should merge Omaha ( project that currently does the same
thing for Windows.

Cross related issue on Omaha:
http://code.google.com/p/omaha/issues/detail?id=1

I know that this could be hard but the potential benefits are huge.

Original issue reported on code.google.com by sorin.sb...@gmail.com on 2 May 2009 at 12:20

GoogleCodeExporter commented 9 years ago 
These really are separate projects.  Omaha is in C++ and very Windows-specific 
since it runs off the registry; update-engine is almost entirely in Objective-C 
and needs special parameters for GUIDs (UUIDs) for machine, user and product 
since Omaha is using the Windows registry for these things (or, for user GUID, 
generating them itself).  

However, this brings up a salient point.  The update-engine codebase is 
woefully out of date with respect to the actual implementation used in the 
GoogleSoftwareUpdate.app.  I am implementing an Omaha-style system with support 
for reporting events to the server, anonymized machine ID and user ID, and 
uninstall.  (I should note this runs on demand and not as an agent, and uses 
the Authentication Framework so the user authenticates like a normal Mac 
Installer and knows when things are changing at the system level.)  

I would prefer to port some of this back but in order to get around system 
design problems I think I am diverging from the original direction of the 
project.  The clearest example is  the global persistent KSFrameworkStats to 
get around those nifty-looking but restrictive process-pipes (a single callback 
would be much simpler and make the fact that you are actually passing several 
objects along the pipe much clearer).  The KSStatsCollection itself is a flat 
dictionary, forcing you to maintain product-specific stats by munging the 
productID into the key (productID///stat_name) and as a persistent store you 
can't use the stats to report to different urls without breaking it up into 
sub-dicts (by serverURL, based on product).  So I am trashing the design 
direction a bit such that merging back into the main branch would be onerous.  

Would it be possible to update the code with what you (Google) are actually 
using now for Omaha-style messages?  Then it would be a lot easier for me to 
figure out how you wanted to finish the project in that regard and I could 
contribute any other fixes I have.

Cheers,
Pete

Original comment by peter.ta...@gmail.com on 22 Jun 2010 at 4:22