search

trinhdunh / update-engine

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

Use existing sparkle infrastructure #1

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Currently there are a lot of applications that make use of Sparkle and
Sparkle+ to get application update information. Make update-engine read the
appcast information and keep those applications up to date without needing
to change their infrastructure to update-engine.

Original issue reported on code.google.com by cforsy...@gmail.com on 29 Sep 2008 at 10:11

GoogleCodeExporter commented 8 years ago 
That's certainly possible. The implementation of this would be a new subclass 
of KSServer, likely named 
KSSparkleServer (or KSAppcastServer). Then, when using the Objective-C API, you 
would configure UpdateEngine 
to use this new server by calling +[KSUpdateEngine 
setServerClass:[KSSparkleServer class]] (declared in 
KSUpdateEngine+Configuration.h).

However, the normal plist that Update Engine uses is pretty simple and 
flexible. Take a look at the 
documentation in 
http://code.google.com/p/update-engine/wiki/PlistServerConfiguration. It's 
probably easiest 
to just fill in the few values required in the Update Engine server plist and 
be on your way. Update Engine is not 
(and wasn't intended to be) a drop-in replacement for Sparkle.

That said, if someone (you) wants to write a KSServer subclass that talks to 
Sparkle appcast servers, that's fine 
with us! :-)

Original comment by dev...@gmail.com on 1 Oct 2008 at 12:42

GoogleCodeExporter commented 8 years ago 
That would mean that I would not only need to maintain a sparkle appcast file, 
but also an update-engine file, 
which to me is problematic. Basically my assumption is that end users will not 
all install update-engine, but 
say for Perian or Growl, we would need to ensure that the user is up to date, 
and that's very controllable with 
Sparkle. Given the choice, we're going to have to go with sparkle (I'm sorry, I 
hate when people say "I'm not 
going to use your app if it doesn't do this!", not trying to do that, just 
making a point) since it allows us more 
control, unless I misunderstand how update-engine works.

Anyhow, what I was looking for was for update-engine to read the appcast 
infrastructure already in place, not 
to replace the sdk or anything else that sparkle does.

Original comment by cforsy...@gmail.com on 10 Oct 2008 at 5:04

GoogleCodeExporter commented 8 years ago 
Why would you need to maintain both a sparkle appcast and an update engine 
plist? You would only need one or 
the other. Not both. If you use Sparkle to update your product, then use the 
appcast. If you use update engine, 
then use the update engine plist.

"Basically my assumption is that end users will not all install 
update-engine..." makes me think that you're not 
clear on what update engine is. Update engine is not for end users. It's for 
*developers*. Developers add it to 
their apps to keep their apps up-to-date. If you're currently happy with 
sparkle, then there's nothing you need 
from update engine.

Original comment by dev...@gmail.com on 10 Oct 2008 at 5:15