The only main difference is the difference in bandwidth necessary for you and the bandwidth I have to buy. It would actually take LONGER to slipstream the DriverPacks, for example in method 2 everything would have to be re-compressed and I can tell you that takes longer than just 30 seconds - which is the time necessary at most for slipstreaming each DriverPack.

I can tell you however that I'm working on something that will make this possible, but more than just this... [/end sneaky mode]

Also, take note that I HATE when games (taking them as an example since they happen to have large patches most of the time) only offer incremental updates/patches.
I like to DL the ver. 1.0-current all-in-one update so I can delete the old one and won't have to apply several patches in case of reinstall to get to current state.

The driver updates aren't that big if you are on broadband (granted, it's quite a pain on modem but I don't think you'd be bothering with the whole UWXPCD then (creating one on your machine, that is, obviuously you'd even more like to USE it as it means you have to DL less on the once installed OS).

Having only the latest FULL version up on the server (or at least lined to), is my understanding of KISS.
You download the package and you can be sure it's up-to-date.
Nothing worse than having a DL page with several versions that all need to be applied in a certain order (IL2, can you hear me?!).

What I would like is either have the BASE auto-DL the newer packages once detected (much like it does with the BASE file itself) or at least provide you with a clickable link to the file/the DL website.
That would be most welcome because as of now it only informs me of a new version - the same can be achieved by visiting this Forum, something I do more often than opening BASE

Using incremental updates, you'd have to integrate them into the larger DriverPacks somehow, unless you want to split those up (say one pack for each device).
That, however, would be most unpractical, as that would mean hundreds, if not thousands of packs - hard to keep track of IMO.
Integrating them into the larger packs means you have to uncompress that pack, replace/update the respective files and repack it.
That takes quite some time, as you'd have to use 7-Zip high compression methods to achieve small filesize, and the requires CPU power and not to forget lots of RAM.

For me, it takes less time to DL a full new pack than uncompressing and recompressing would.
This is only a solution for a fast, powerful PC with a slow internet connection.

So, unless you want to save Bâshrat the Sneaky some bandwidth I fail to see the real advantage of an incremental update approach.

you like the KIS principle too, eh?

I should have said, I think it won't be done (rather than it won't be simple)

Something else to consider with this - you would have to keep track of updates as they relate to several prior versions.  Personally I would love it if all the tools out there did not support this constant going over the same source again and again.  It would probably eliminate about 75% of the threads that have a subject line like "Help!"

2klik base, have it run update before setting options.
result, update check sees what's needed.
user says NO.
goes to options
runs with older packs it knows it was good for.

2klik base, updates are allowed by user
no new base module, just finisher and increments.
gets new basexxx (mandatory) saves to user defined download folder
gets finisher for the session into working folder(mandatory)
gets increments into working folder (mantatory)
runs scripts for update=unzip + unzip /delete/adds and rezips, incremental addonpack gets deleted.
(unzip + unzip +rezip = so many seconds of time)
set options.
runs with updated packs.

updated packs tell old base it has to be updated if old base is run 8-) (paradox..)

your old copies of base and the old packs are still where you had them before you copied them to working folder.
new basexxx saved someplace by mandatory download.

I think it won't be simple.

probably a h*ll to code. I think filtering drivers is not easy.

suppose DPsBase is run, and its update check finds a newly refreshed or newly added part in a pack what requires a few new exceptions entries for the filter in DriverPacks-Finisher.
If the finisher is not updated simultime, bad joss.

suppose further that a fix or update requires a newer base...
'edit: (if finisher has to be updated, base would have to be, for it is in its sfx.)

update, and start itselt fresh? Then get the newer increments?
edit: then you'd have to make that mandatory?

I am not a coder, but think it would not be as easy as it sounds.

OTOH, it might be really simple. I knoweth naught about coding

you mean.. like in incremental?

I have seen that Most of the Driver Packs usually replaces when they reached to an updates one....I think there is no need to Provide a whole Update Package every time until that is not become a huge update,Instead of doing this you may Provide Update Patches for them...Users always Irritate when they Made thier UXPCD and then the New Drivers Pack version Releases...
I know It is quite a typicall job...But this is a better way for all of us...
DBase may Have an Update Patch Option which will Prompt the User to get those small Updates...