On Thu, Mar 15, 2012 at 5:52 AM, Rob Weir <robw...@apache.org> wrote:
> On Thu, Mar 15, 2012 at 7:47 AM, Oliver-Rainer Wittmann > <orwittm...@googlemail.com> wrote: > > Hi, > > > > I have continued the work started by Regina, Ariel and Kay regarding the > > update service. > > I have documented my findings at [1]. > > > > I think we have everything together to bring a corresponding web service > > back to life. > > > > I think we have at least two options for such a web service. > > > > If we want to create a 'real' web service which on demand creates an > > appropriate response the HTTP GET request contains all needed > information in > > its header fields "User-Agent" and "Accept-Language" to implement such a > web > > service. > > The "User-Agent" field contains the operating system, the machine > > architecture and the bundled languages of the installed office. If a > > corresponding installation package of newer version is available a > > corresponding response can be generated. > > > > Another solution could be to provide a static XML document, based on an > atom > > feed, which contains as much entries as installation packages for the > latest > > version are available. For each installation package which defines > itself by > > the operating system, the machine architecture and the bundled languages > an > > entry is needed. Such entries need to be duplicated for every existing > > office installation with different <UpdateID> in its version.ini. > > > > Any thoughts, comments, corrections, ...? > > > > My opinion: > > This is an example of a "low rate of change" application. The data > changes every few weeks or months, not daily or hourly. It is also a > high traffic service, especially when we have millions of clients > doing automatic update checks. So a static file is probably better > for server load/performance. > > I wonder if the static XML file could be automatically generated via a > script? Maybe part of our release script? (I assume we'll eventually > have a release script that deals with cutting RC's, doing the code > signing, etc.) > I need to check Oliver's updates to our documentation, but my thought was in agreement with what your propose Rob (if possible) - - at least for the base product, generate the XML nightly(?) for available updates. I hit a wall in many areas, not the least of which is the actual format of the XML feed. Then, we get to deal with "fact finding" -- what do we have and how do we determine products, buildids, etc. From what I could gather so far, there was some sort of "backend product" that required manual entry of these kinds of params. Assuming we could actually manually create (now) such and XML feed, at some point we would need to spend time in (perhaps) standardizing on build names etc to do something more or less "automatically", and by this I mean, not a web service but just a feed generation. Then, of course there's the extension updates....somewhat the same, somewhat different. > > BTW, the update service of a certain installed office can be tested > locally. > > No HTTP GET request is involved in this case, but you can test with > certain > > XML documents provided as responses. You can change the value of > <UpdateURL> > > in file <version.ini> of your office installation to a local file URL - > e.g. > > under Windows to something like file:///C:/check.update.xml > > > > [1] > > > http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release > -- ---------------------------------------------------------------------------------------- MzK "Follow your bliss." -- attributed to Joseph Campbell
