On Tue, May 22, 2012 at 6:21 AM, Oliver-Rainer Wittmann < [email protected]> wrote:
> Hi, > > > On 16.05.2012 13:24, Oliver-Rainer Wittmann wrote: > >> Hi, >> >> as our release AOO 3.4 is out now for more than a week I think it would >> make >> sense to reactivate a simple update service for installed OOo 3.3 >> versions. >> I have already seen a post on the users mailing list that the update >> functionality is not working in OOo 3.3. I assume that corresponding >> posts also >> exist in the forum. >> From my point of view it is time to let our OOo 3.3 users know via the >> update >> functionality that we have released AOO 3.4. >> >> The update URL for OOo 3.3 is: >> http://update36.services.**openoffice.org/**ProductUpdateService/check.** >> Update<http://update36.services.openoffice.org/ProductUpdateService/check.Update>(plus >> a query part ?pkgfmt=<pkgformat> for non-Windows platforms) >> >> As this URL resolves to nothing, the user currently gets the following >> response >> from the update functionality in OOo 3.3: >> Status: Checking for an update failed. >> Description: Error reading data from the network. >> Server error message: Could not read status line: An existing connection >> was >> forcibly closed by the remote host. >> >> There are two solutions: >> >> (A) "static" solution: >> Provide an XML document similar to the one which is attached when an HTTP >> GET >> request to the above given URL is made. >> The attached XML document contains an atom feed according to [1] >> Currently, it only contains entries for: >> - German, Windows >> - German, MacOS X >> - German, Linux, 32bit >> - German, Linux, 64bit >> - English-US, Windows >> I hope I got the inst:os and inst:arch content right for all the >> platforms. >> For Windows and MacOS we could directly provide download links. Thus, the >> update >> functionality can download it and install it on corresponding user demand. >> For Linux we can not distinguish the different needed package formats in >> this >> "static" solution - as far as I know. Thus, a landing page can be given >> here. >> The update functionality can open it in the user's default browser on >> corresponding user demand. In the attached XML document I included our >> AOO 3.4 >> release announcement page as this landing page - this is only a proposal. >> The final XML document needs to be extended by entries for all possible >> combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit, >> Linux >> 64bit) for each language which we had released for AOO 3.4. >> It would be also be possible to include more combinations for which we >> have no >> package. We could create a special landing page for these which state >> that AOO >> 3.4 is out and that the user might want to have a look, if one of the >> provided >> packages would fit her/his needs. >> >> For this solution we need to provide the XML document at the above given >> URL. >> >> (B) "dynamic" solution: >> As the HTTP GET request contains all the information needed to identify >> the >> installed version performing the HTTP GET request - see [2], with some >> server-side logic an XML document could be dynamically created which >> servers the >> identified version. >> E.g.: >> <?xml version="1.0" encoding="UTF-8"?> >> <inst:description xmlns:inst="http://**installation.openoffice.org/** >> description <http://installation.openoffice.org/description>"> >> <inst:version>- Apache OpenOffice 3.4</inst:version> >> <inst:buildid>9590</inst:**buildid> >> <inst:os>Linux</inst:os> >> <inst:arch>x86</inst:arch> >> <inst:update type="application/octet-**stream" >> src="http://sourceforge.net/**projects/openofficeorg.mirror/** >> files/stable/3.4.0/Apache_**OpenOffice_incubating_3.4.0_** >> Linux_x86_install-deb_en-US.**tar.gz/download<http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.4.0/Apache_OpenOffice_incubating_3.4.0_Linux_x86_install-deb_en-US.tar.gz/download> >> " >> /> >> </inst:description> >> which would serve a OOo 3.3, en-US, Linux 32bit, packgage format deb >> If there is no AOO 3.4 for the identified OOo 3.3 the script should >> create the >> following XML document: >> <?xml version="1.0" encoding="UTF-8"?> >> <inst:description xmlns:inst="http://**installation.openoffice.org/** >> description <http://installation.openoffice.org/description>"> >> </inst:description> >> >> For this solution we need some server-side based script reacting on the >> above >> given URL, which can evaluate the provided information and can create XML >> documents as given above. >> >> [1] http://wiki.services.**openoffice.org/wiki/Update_** >> Notification_Protocol<http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol> >> [2] >> http://wiki.services.**openoffice.org/wiki/Update_** >> Notification_Protocol#summary_**information_about_request_to_.** >> 3CUpdateURL.3E<http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#summary_information_about_request_to_.3CUpdateURL.3E> >> >> >> I would prefer the "static" solution as a short-term one which could be >> working >> next week. >> For the "dynamic" solution a script is needed. I have no experience in >> programming such a script. Is there a volunteer who would take over this >> task? >> > I don't have any ideas at all in what would be included in such a script...so no help from me. And, I wonder if something like that was ever in operation. With no knowledge, I can't say. > >> >> Any thoughts/comments/**improvements/changes/...? >> >> >> > It looks like we can go with the "static" solution as a short-term > solution. > Sounds good. this is reasonable and should work assuming infra can deal with handling the "pkgfmt" bits for Linux, for example. > Thus, I will do the following: > - Creation of a complete XML document > - Include entries for at least one languages for which we have currently > no AOO 3.4 installation package. > - Providing the XML document and possible variants on [3] for testing and > verification. > - Call for volunteers to test the XML document at [3]. > - Integrate feedback, if we want to have direct download links or links to > a certain existing web page for manual download. > I don't understand this one. Initiate update vs letting user choose and then do installation on their own? > - Activate the update service > -- move the final XML document to [4]. > -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. > > My goal is to have the update service for OOo 3.3 running at the end of > next week. > > Any objections? > > Any volunteers in advance which want to test? > If yes, please provide information about your OOo 3.3 installation > (operating system and language) and the test cases (direct download link, > link to download page, ...) you want to test. > > [3] > http://people.apache.org/~orw/**testupdateservice/<http://people.apache.org/%7Eorw/testupdateservice/> > [4] http://www.openoffice.org/**projects/update36/** > ProductUpdateService/check.**Update<http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update> > [5] http://update36.services.**openoffice.org/** > ProductUpdateService/check.**Update<http://update36.services.openoffice.org/ProductUpdateService/check.Update> > > > Thanks in advance, Oliver. > All sounds good Oliver. I cant' help with further testing, but I do hope all goes well. -- ---------------------------------------------------------------------------------------- MzK "The reports of my death are greatly exaggerated." -- Mark Twain
