Journal of a modern day knight

70000 served and more everyday

Curtis — Fri, 31 Mar 2006 03:24:51 +0000

I was looking over some of the statistics and dates. They are continuing to move higher.

March 26 2005 - autopackage 1.0 released

July 23, 2005 - download counter started
July 28, 2005 - autopackage 1.0.5 released

March 29, 2006 - recorded 70000 support code downloads[*]

So in for the last 8 months, we around averaging 9000. Not bad at all. There is a definite building trend where 4 months ago, per day was ~200. Currently 360-420 is the daily average.

* Recorded support code downloads are not counted from mirrors or represent the total number of support code installed.

distributed updates are alive

Curtis — Thu, 05 Jan 2006 03:37:13 +0000

I was able to sit down and look through the dependency retrieval code of autopackage’s support code. The short story is that I put together some logic to use an application’s luau xml repository file to search and install a .package . The long story is that there were logic issues with the existing code so at least this exposes a code path that was not being used at all.

The update service will become another component of rootname management. The package (rootname) database holds information about the project’s rootname and current release. The rootname table should closely match the project’s apspec file. A master file would be downloaded to search for a project name and quickly see if an update is available. If you continue the process, the luau downloader will obtain the project xml repository to find where to download the .package. The downloaded .package is executed like a typical install session sequence.

Scenario:
`package search gaim’
download master package information list
try to match shortname gaim against master package information
if match found - check for update against SoftwareVersion (and future PackageVersion)
if update available use repository uri to download .package meta
install .package

I will update cvs with a patch to correct the logic issues and submit the new logic patch to the ml soon.

Luau to update applications

Curtis — Tue, 22 Nov 2005 03:31:27 +0000

Currently autopackage uses a (modified) version of luau to download repository xml files, compare software entries, and download .packages to satisfy a requirement. All of these actions are for dependencies and not for applications. An oft requested feature is a way to search for an (unknown) application or update/upgrade an application.

The searching for a package was made slightly better by having the package database listing. It would be better if the support code could query the database and go forward to download the package directly. Still nicer would be for the support code to know when an update is available for an installed package and that would start the download process.

My movement to both of these features was the statistics reporting framework. An xml file could be generated such that a client could download the repository xml file, compare versions, and download the update. The same sort of idea could be done for the searching. The idea was the currentversion data in the rootname table would announce the version available for updates. The repository xml file url in the rootname table would give the details to satisfy the requirements for the update.

What I do not know is a] what to use from luau or b] just do the entire process without luau. In using luau, a user/developer could use a repository feed for any type of package (rpm/deb/autopackage). Once the feed is registered in luau, it would be listed and managed by the luau client. For autopackage use, there are many layers and almost all of them could use luau in some way. The other way would be to use xml/xslt to get the data in a format in which comparisons are handled until a .package file can be located and downloaded for processing.

Layers:
Discovery ( Search ): autopackage
Discovery ( Update ): autopackage
Update ( Compare ): autopackage or luau
Manage ( Repository): autopackage or luau

I do not think a searching/updating feature is going to be that complicated using the rootname table as the forwarding service mechanism. Just not sure how much we need to continue to use from the luau project going forward or how much we have to do from xml/xslt scratch.