DonationCoder.com Software > DcUpdater

DcUpdater v2 Preliminary Flirtations

<< < (8/8)

Perry Mowbray:
it's main value will be when navigating very large listings -- perhaps if one were viewing potential applications that could be installed or something like that.
-mouser (March 23, 2009, 07:05 AM)
--- End quote ---

NANY 2010?  :D

tomos:
i can see the confusion.  the second level grouping would make more sense as

    * Applications: FARR
    * Applications: Other
basically what it's doing is giving a "folder" to anything with more than 1 item, and then putting all other singletons in the "Other" folder.

Let's not get too hung up on this grouping option -- i think i agree with the general sentiment that it just makes things more messy and hard to take the information in.  it's main value will be when navigating very large listings -- perhaps if one were viewing potential applications that could be installed or something like that.
-mouser (March 23, 2009, 07:05 AM)
--- End quote ---

okay, (not to get hung up on it) but in case you do go ahead with it -
my point was that I thought there was no need to group at all at the second level (apart from stuff like FARR plugins). In fact I think it would just make it harder to see clearly

Perry Mowbray:
Not that I use it very often, but I like Software Informer's interface: It gives you a compact list with salient details, and expanded details at a click of the mouse.

phitsc:
Hey, it's over two years since the last presentation of DcUpdater v2. :P

justice:
There are a few things that I think DcUpdater could do that I have stumbled upon whilst developing an app. I'm experimenting with downloading patches and applying these to the main program.  From the perspective that dcupdater does not download the whole program, and also the related situation that you want to update from a specific version x to specific version y:

* You can currently append the current version number to the querystring of VersionFileRemote and serverside parse this and return a Version File suitable for the right upgrade path. Alternatively perhaps DcUpdater could support this better?
* I'm hoping to have DcUpdater download a zip file composes of a .diff made with gnuwin32 diff utility and a bunch of .bsdiff's created with bsdiff (binary diffs), together with a patcher app. Perhaps DcUpdater could in the future support this better? This helps in my situation where I don't want people to download the whole app using just dcupdater and a .dcupdate definition.
* Because of the patches scenario I have to check the base version and get the right patch archive - perhaps I want to run a checksum on a group of files and compare that with a checksum in versioninfo instead of using manual version numbers which are prone to errors (for example I might reissue a version because of a bug). Perhaps DcUpdater could in the future support this better?

Hope that's useful :)

Navigation

[0] Message Index

[*] Previous page