Coffeehouse Thread

25 posts

Incorporate RSS into the next version of Windows Installer

Back to Forum: Coffeehouse
  • Devils​Rejection

    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.

  • Manip

    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.




  • Steve411

    God please no.

    - Steve

  • burtriddley

    Click-once has the distribution and security licked. Good for apps, but not drivers and such.

  • lukes

    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.

  • Jeremy W

    I would far rather have the installer ask me if I want to subscribe to the release blog for the product.

  • billh

    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. 

    BillH,
    MVP-in-training

  • Karim

    billh wrote:
    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:

    http://www.installshield.com/products/updateservice/

    Likewise Microsoft could open up Microsoft Update to other manufacturers, I suppose...

  • billh

    No, seriously.   Imagine:

    <?xml version="1.0" ?>
    <channel>
    <title>Microsoft Notepad</title>
    <link>http://www.microsoft.com</link>
    <description>This is the source code for Notepad.  Compile at your own risk.</description>

    <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.

  • Steve411

    billh wrote:
    No, seriously.   Imagine:

    <?xml version="1.0" ?>
    <channel>
    <title>Microsoft Notepad</title>
    <link>http://www.microsoft.com</link>
    <description>This is the source code for Notepad.  Compile at your own risk.</description>

    <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.


    But Microsoft does not support the open source initiative in their software, even if its a piece of crap such as Notepad.

    - Steve

  • Karim

    billh wrote:
    No, seriously.   Imagine:

    <?xml version="1.0" ?>
    <channel>
    <title>Microsoft Notepad</title>
    <link>http://www.microsoft.com</link>
    <description>This is the source code for Notepad.  Compile at your own risk.</description>

    <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.


    I keep waiting for the punch line.  Either that or the closing </brain-damaged-idea> tag.

    You're joking, right?  Now you're not talking about patches, you're talking about source code for entire executables????

    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.

    I know, I know.  "But it uses RSS!!!!"

  • BruceMorgan

    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.

  • Manip

    billh wrote:
    No, seriously.   Imagine:

    <?xml version="1.0" ?>
    <channel>
    <title>Microsoft Notepad</title>
    <link>http://www.microsoft.com</link>">http://www.microsoft.com</link>
    <description>This is the source code for Notepad.  Compile at your own risk.</description>

    <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=1739
    Record-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? Wink




  • AndyC

    Manip wrote:


    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.

  • Manip

    AndyC wrote:
    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.

  • billh

    Karim wrote:
    You're joking, right?  Now you're not talking about patches, you're talking about source code for entire executables????


    No, I'm serious.

    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.  Smiley

    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.

  • David7738

    billh wrote:
    Karim wrote: You're joking, right?  Now you're not talking about patches, you're talking about source code for entire executables????


    No, I'm serious.

    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.

  • AndyC


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

    That's 20 minutes you could spend better having fun! Smiley

    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.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.