Think about this for a second. People (developers) use the Windows Installer as a platform for their programs, vista has the RSS api built in, just add your rss feed, with an enclosure for updates, into the OS itself.

The OS (Vista) then periodically checks all the RSS feeds that are capable of recieveing updates and downloads and installs all updates that it has to.

Think about how mnay problems this solves. Drivers being auto updated. Applications being auto updated. Updates pushed out automatically.

Make this all transperent to the user. I believe the power of RSS and it's integration into Vista has the potential for this.

Make the next version of Windows Installer have this so that companies can stop worrying about informing their customers about new versions. Have their software update automatically.

Can you imagine all the problems that would cause?
I mean spyware, virii setting up their own auto-updaters... Even if you remove the spyware, if you forgot to remove the RSS feed then it will get re-installed by the Operating System for you, and even with administrative privileges (if the OS is capable of
updating drivers).

Not to mention all the legitimate applications that will abuse this functionality to install demos that they think you will want to try... I mean Quick Time and Real Player abuse what the OS already exposes, imagine giving them more guns?

Anyway, by the time you out-line the format that an RSS feed must expose for Windows to be able to find the download and how to run it you might have well save the bandwidth / CPU and just use plain text files (*.upd ?). I for one don't want 60% of my CPU used
for five minutes while Windows interprets all the rich format RSS feeds.

Allowing an application to auto-update via RSS is a no. But through windows installer allowing the developer to specify an RSS feed which, if the user is connected to the network, will then show the feed while the application is being installed within
the installer.

I think it would be beneficial to have small apps distributed by RSS. Better yet, pack the code itself into XML tags and have the user parse and feed it through a compiler on their end. Think about it. Text moves faster than monolithic executables across
networks.

If you are going to do drugs and then post, you have to share with all the other Niners... it's the rule....

Actually if you take a binary and Base64-encode it, that makes it LARGER not smaller...

I think you guys are getting bogged down in the idea of how to distribute the updated bits. It's a non-trivial problem due to security issues. Plus you are possibly reinventing the wheel (how about using the BITS service?)

It would be relatively EASY to come up with a convention so that makers of software could publish their latest versions at a well-known address. This address could either be fixed or discoverable using UDDI. Once you know that address, pretty much anything
can "check" to see whether there are newer versions of software available.

The first step would be a single page a user could visit to see which packages on their system need updating. THEN you can start worrying about distribution, security, installation etc.

FYI InstallShield already sells this as a product. If it became "standard," then users would have one place to check for all non-Microsoft software updates, and developers wouldn't have to invent the wheel each time:

Saying that people should compile source code just to get an update to a program is like saying everyone should get a prefrontal lobotomy so they can be "on par with" retarded people. In an age where Linux distros are TRYING to catch up to the simplicity
and security of Microsoft Update, you are saying we should all take a HUGE leap BACKWARDS and compile source code.

The Active Channels technology in IE (aka CDF) supports "Software
Update Channels", which could do something like you suggest. Reading that old document from a 2005 security perspective is interesting, to say the least.

CDF, of course, is one of the many precursor technologies to RSS and Atom. Active Channels wasn't successful and we've removed support for it from IE7 in favor of RSS support.

Using RSS to distribute the bits has many security issues. I like the idea of extending MSI to allow the user to subscribe to a news feed about the product.

<item>
<title>Line one of the code</title>
<description>int main(void){</description>

...and so on. It puts it on par with Linux (compile your own source), AND, get this, uses RSS.

Microsoft Update Format=1.0
CRC=0x9B39C1
Size=1739Record-Init
name=Microsoft Notepad
link=http://www.microsoft.com
description=This is the source code for Notepad. Compile at your own risk.Item-Init
title=Line one of the code
description=int main(void){Item-Init
title=Line two of the code
description=return -1; }

Record-Init
name=.....

Look at how much CPU I saved by ignoring all the useless formatting rules XML adds... Also, if a record or item is corrupt the rest will work fine (the system resets on each Record-Init); unlike XML, in which if you forget a single < / > tag the entire thing
goes to heck. With my format, a record or item end is implicit though a new Record-Init, Item-Init or the end of the file.

But really, each to their own, if you want to over-use XML and create laggy applications then that is your business...

PS - Firefox, an XML heavy app takes almost ten seconds to load from a cold launch, IE takes around half that or less... I wonder what all that extra time is being used on?

Look at how much CPU I saved by ignoring all the useless formatting rules XML adds... Also, if a record or item is corrupt the rest will work fine (the system resets on each Record-Init); unlike XML, in which if you forget a single < / > tag the entire thing
goes to heck.

Look how much development time you lost by having to write a parser rather than just using a prewritten XML one. Look how much flexibility you lost by having such a rigid format. Look how quickly your format breaks if the corruption is
on the Record-Init line and how your format doesn't allow you to identify that corruption.

I really think you just don't get XML. And Firefox taking longer to load has nothing to do with XML, which can be parsed pretty quickly, and everything to do with poor optimisation of the loader.

Look how much development time you lost by having to write a parser rather than just using a prewritten XML one.

Yes, when will I find twenty minutes to write a parser! ... 8-)

AndyC wrote:

Look how much flexibility you lost by having such a rigid format.

Look at how much consistency I gained by having such a rigid format. You will never have someone write a bad parser because or generator because they can follow the guidelines so exactly.

Further more, using the version number on line #1 you can write updates.

AndyC wrote:

Look how quickly your format breaks if the corruption is on the Record-Init line and how your format doesn't allow you to identify that corruption.

What? If a record-init is missing you loose a max of two records, the one before it and after... If you wanted to waste the bits you could add a Record-End, but with that you might have well use XML... This way I save the time and space.

AndyC wrote:

I really think you just don't get XML.

I think you don't understand just how much slower XML is to parse than the above format, and how little you would gain.

It's simple. Offload the compilation onto the customer. Let them build the app. It would save a lot of time for Microsoft. You wouldn't need to ship CDs anymore. With everybody having access to broadband, it's feasible.

I fail to see the downside of shipping all of your code through XML. Holding my RSS hammer, everything begins to look like a nail.

It's simple. Offload the compilation onto the customer. Let them build the app. It would save a lot of time for Microsoft. You wouldn't need to ship CDs anymore. With everybody having access to broadband, it's feasible.

I fail to see the downside of shipping all of your code through XML. Holding my RSS hammer, everything begins to look like a nail.

Everyone does not have access to broadband! Have you any idea of the size of these files .. most companies will never release source code even obscured code.. Instead of shipping a DVD with Vista on it they will have to ship an initial spindle of dvd's (assuming
that everyone has a DVD (and the market penetration of CDROM technology took almost 10 years before it became mainstream) (being one of the first vendors of CDROM technology back in the 1x days helps)

Then there is the 100G HD to hold this source and the week to compile it all.. yikes!! then there is the problem of a user tinkering with the compile switches.. what a support headache..

A few years ago Cnet (download.com.com) had a utility that would check the current versions of just about all your installed software and would tell you if an update was available.. Now this would be useful (MR Tech Systray Pro has this today but for a select
number of products.. not all KB articles are important.. and installing all of them can be detrimental to your computer.. (I found this out the hard way). Sorta like bios updates.. unless the update fixes an issue you are having (no problems then don't update)
then it is better to wait just in case the NEW update breaks something else.. Better the devil that you know ....

keeping all your installed software up to the current CVS is a daunting operation.. Actually most customers would rather have the OS in ROM and have instant boot up.. lightning program startups.. but this is just not practical.. even the game consoles got rid
of code in ROM a long time ago.

Look at how much consistency I gained by having such a rigid format. You will never have someone write a bad parser because or generator because they can follow the guidelines so exactly.

Sure someone can write a bad parser/ generator for it - only takes someone to assume the order of items is fixed, for example.

Further more, using the version number on line #1 you can write updates.

So now you need two parsers, to deal with version changes. And you still don't get third party extensibility.

What? If a record-init is missing you loose a max of two records, the one before it and after... If you wanted to waste the bits you could add a Record-End, but with that you might have well use XML... This way I save the time and space.

No, if Record-lnit is corrupt the contents of the second record get merged into the first and you've no way to detect the error. For an update system that would seem a poor design.

I think you don't understand just how much slower XML is to parse than the above format, and how little you would gain.

???

An XML stream parser without validation can easily be as fast as a plain text one in a situation like this, particularly given that there are plenty of highly optimised ones out there already. If speed + number of bytes was really that much of an issue, why
aren't you advocating using a binary format? And I'd consider the ability to allow third party extensions to the format without risk of breaking stuff (via XML namespaces) to be a worthwhile reason on its own.