Re: How to handle the downloads?
Am 08/04/2011 01:57 AM, schrieb Dave Fisher: On Aug 3, 2011, at 4:31 PM, Gavin McDonald wrote: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Thursday, 4 August 2011 8:54 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Am 08/04/2011 12:38 AM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 6:45 PM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Am 08/03/2011 02:17 AM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 9:40 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Am 08/02/2011 11:03 PM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 12:55 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Thanks for you note. Then we should implement adownload method withthe fllowing order: 1. User clicks on the One-Click-Download URL and get the software (like today on download.openoffice.org). 2. If not, he can use alternative download links (like today on download.openoffice.org/pther.html). 3. If a special mirror has to be used, the list of all available mirrors will help (like today on http://distribution.openoffice.org/mirrors/#mirrors;). Latest with step 3 all users should be able to download something. Yep, all possible here at the ASF right now. See www.apache.org/mirrors for our equiv of step 3. I've already understood that you don't want the OOo mirrors but that we should use the Apache ones. ;-) Hi Marcus, don't count me as 100% on that yet, I want to know more about the OOo mirrors too. OK, if you have already questions just ask and I will try to give answers. not yet, working on it, I just didn't want to be maintaining 150+ projects on one mirror system and 1 project on another mirror system. maintaining one mirror system is easier, so If that is possible and our mirroring system can cope, and we can maybe coax a few more mirrors our way all the better. Some of our existing mirrors may decide that bandwidth is too much and leave, so we need replacements. I don't know about bandwidth but to get an impression about size and amount please have a look here. This mirror has rsync'ed everything that was released by Sun and Oracle: http://ftp5.gwdg.de/pub/openoffice/ thanks, If it makes sense to try and merge these somehow, I want to pursue that avenue. A first step should be to look for doubles. yep, We may need both for some time, we can not put non ASF releases on our mirroring system anyway so what we are trying to resolve is from our first ASF release onwards. Hm, when looking at this mirror it is already hosting non-Apache software: ftp://ftp.uni-erlangen.de/pub/mirrors/ Software from Apache and, e.g., OpenOffice.org is just a subset within many other projects. Sorry, that isn't what I meant. The mirrors get their content from us right, we can not provide them with non-asf released software to put on their mirror copy of our dist tree [1] . They are of course welcome to provide non-asf mirrors as most of them already do. [1] - http://apache.org/dist/ Gav... OK, let me try again. The mirrors can distribute what ever they want but within the Apache subdirs only ASF licensed software is allowed. Have a got it right now? Spot on. And the only way non ASF licenses software will get into the Apache subdirs is if we put it there in the first place. A project makes a release and puts the files of that release into a specific area of svn. That then syncs up with our main dist area, mirrors then sync up from there. Do we have to commit our binary files into SVN? I hope not. ;-) IOW, the pre-existing mirror system for OOo needs to continue and be referred to in documentation and 'older releases' page so that folks can get pre-asf released versions of OOo from there. Only new releases from now onwards developed here at ASF will be put into our release/dist areas. Yes, sounds a reasonable separation. However, when we don't migrate our Mirrorbrain load balancer, then we need a new method to choose an appropriate mirror as the current download.cgi works only for ASF mirrors. Here is the big question. As long as the Apache hosted version of download.openoffice.org points to mirrors with already existing OOo releases that were put on the mirrors by Oracle/Sun then we are A-OK? Correct? If so, then I think we are good to go as long as it is clear what is AL2.0 and what is not. Then the implication is that the magic on the download pages should clearly indicate AL2.0 or legacy - maybe with color, a title change and an Apache feather icon. Is that enough for us to keep JFDI? Regards, Dave Marcus Am 08/02/2011 04:38 PM
Re: How to handle the downloads?
Am 08/03/2011 02:17 AM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 9:40 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Am 08/02/2011 11:03 PM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 12:55 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Thanks for you note. Then we should implement adownload method withthe fllowing order: 1. User clicks on the One-Click-Download URL and get the software (like today on download.openoffice.org). 2. If not, he can use alternative download links (like today on download.openoffice.org/pther.html). 3. If a special mirror has to be used, the list of all available mirrors will help (like today on http://distribution.openoffice.org/mirrors/#mirrors;). Latest with step 3 all users should be able to download something. Yep, all possible here at the ASF right now. See www.apache.org/mirrors for our equiv of step 3. I've already understood that you don't want the OOo mirrors but that we should use the Apache ones. ;-) Hi Marcus, don't count me as 100% on that yet, I want to know more about the OOo mirrors too. OK, if you have already questions just ask and I will try to give answers. I just didn't want to be maintaining 150+ projects on one mirror system and 1 project on another mirror system. maintaining one mirror system is easier, so If that is possible and our mirroring system can cope, and we can maybe coax a few more mirrors our way all the better. Some of our existing mirrors may decide that bandwidth is too much and leave, so we need replacements. I don't know about bandwidth but to get an impression about size and amount please have a look here. This mirror has rsync'ed everything that was released by Sun and Oracle: http://ftp5.gwdg.de/pub/openoffice/ If it makes sense to try and merge these somehow, I want to pursue that avenue. A first step should be to look for doubles. We may need both for some time, we can not put non ASF releases on our mirroring system anyway so what we are trying to resolve is from our first ASF release onwards. Hm, when looking at this mirror it is already hosting non-Apache software: ftp://ftp.uni-erlangen.de/pub/mirrors/ Software from Apache and, e.g., OpenOffice.org is just a subset within many other projects. Marcus Am 08/02/2011 04:38 PM, schrieb Donald Whytock: A consideration...I for one have a need to be able to select my mirror. My office's firewall blocks certain domains and websites, especially those recognized as hosting or file-sharing sites. It does not, however, block .edu sites, so when I download an Apache product I select a university mirror. Other users may have similar constraints. If OOo's download process is going to tie into Apache mirroring, please don't completely eliminate the capacity to select the mirror. Don
Re: How to handle the downloads?
I've created a little diagram how I think the download has to work: http://incubator.apache.org/openofficeorg/docs/download_process.png As it seems we cannot go on like we did with OOo the JS magic has to change a bit, how to recognize the language, OS and country to assemble the nearest mirror server + file name to get the download URL. Marcus Am 08/02/2011 01:34 AM, schrieb Marcus (OOo): Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus
Re: How to handle the downloads?
On 3 August 2011 15:47, Marcus (OOo) marcus.m...@wtnet.de wrote: I've created a little diagram how I think the download has to work: http://incubator.apache.org/openofficeorg/docs/download_process.png As it seems we cannot go on like we did with OOo the JS magic has to change a bit, how to recognize the language, OS and country to assemble the nearest mirror server + file name to get the download URL. I'm still struggling to understand why the existing ASF process for selecting the nearest mirror is not appropriate for this. If you use the existing infrastructure then all your JS Magic is not necessary (although I confess to not knowing exactly how the ASF mirror system works, for me it just works). Ross Marcus Am 08/02/2011 01:34 AM, schrieb Marcus (OOo): Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: How to handle the downloads?
Marcus (OOo) wrote: I've created a little diagram how I think the download has to work: http://incubator.apache.org/openofficeorg/docs/download_process.png As it seems we cannot go on like we did with OOo the JS magic has to change a bit, how to recognize the language, OS and country to assemble the nearest mirror server + file name to get the download URL. Marcus Marcus, One thing I would like to ask. That the user _not_ be offered a file that does not exist. We both saw that with the OOo system to many times. From non-existent with JRE plus language to versions for Blackberry. Andy
Re: How to handle the downloads?
On 3 August 2011 15:53, Ross Gardler rgard...@opendirective.com wrote: On 3 August 2011 15:47, Marcus (OOo) marcus.m...@wtnet.de wrote: I've created a little diagram how I think the download has to work: http://incubator.apache.org/openofficeorg/docs/download_process.png As it seems we cannot go on like we did with OOo the JS magic has to change a bit, how to recognize the language, OS and country to assemble the nearest mirror server + file name to get the download URL. I'm still struggling to understand why the existing ASF process for selecting the nearest mirror is not appropriate for this. If you use the existing infrastructure then all your JS Magic is not necessary (although I confess to not knowing exactly how the ASF mirror system works, for me it just works). Oh, wait, the penny might have dropped. Is the JS Magic doing more than finding a mirror? e.g. it is deciding which language pack to download etc. If that's the case then ignore my mail. Ross
Re: How to handle the downloads?
Am 08/03/2011 04:53 PM, schrieb Ross Gardler: On 3 August 2011 15:47, Marcus (OOo)marcus.m...@wtnet.de wrote: I've created a little diagram how I think the download has to work: http://incubator.apache.org/openofficeorg/docs/download_process.png As it seems we cannot go on like we did with OOo the JS magic has to change a bit, how to recognize the language, OS and country to assemble the nearest mirror server + file name to get the download URL. I'm still struggling to understand why the existing ASF process for selecting the nearest mirror is not appropriate for this. If you use the existing infrastructure then all your JS Magic is not necessary (although I confess to not knowing exactly how the ASF mirror system works, for me it just works). I've not said that the ASF process is not appropriate. ;-) For OOo we had our own and I know that and how it's working. However, at the moment I've no clue of the ASF process. Therefore I've first created some boxes to show what is important. If all that we need is already available and working, then fine. So, when we can agree on the diagram, then I would try to figure out how the ASF process works. Marcus Am 08/02/2011 01:34 AM, schrieb Marcus (OOo): Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus
Re: How to handle the downloads?
Am 08/03/2011 04:57 PM, schrieb Ross Gardler: On 3 August 2011 15:53, Ross Gardlerrgard...@opendirective.com wrote: On 3 August 2011 15:47, Marcus (OOo)marcus.m...@wtnet.de wrote: I've created a little diagram how I think the download has to work: http://incubator.apache.org/openofficeorg/docs/download_process.png As it seems we cannot go on like we did with OOo the JS magic has to change a bit, how to recognize the language, OS and country to assemble the nearest mirror server + file name to get the download URL. I'm still struggling to understand why the existing ASF process for selecting the nearest mirror is not appropriate for this. If you use the existing infrastructure then all your JS Magic is not necessary (although I confess to not knowing exactly how the ASF mirror system works, for me it just works). Oh, wait, the penny might have dropped. Is the JS Magic doing more than finding a mirror? e.g. it is deciding which language pack to download etc. Yes, we have to recognize the language and OS to know the appropriate install file to assemble the correct download URL. If that's the case then ignore my mail. Hm, not really, as we could bring together both magics into one process. Marcus
Re: How to handle the downloads?
On 08/02/2011 01:45 PM, Dave Fisher wrote: Kay, -- lots snipped -- http://incubator.apache.org/openofficeorg/www/index.html ok, I jsut updated my svn trunk but before you added this I guess. I'll take a look. I'll start a new thread on something related -- a new logo. Will be there soon. I think I committed more at once than I should. There is a lot of deadwood there that should be removed. Regards, Dave To get headers and footers a template is needed and the view.pm will need adjustment. See http://incubator.apache.org/openofficeorg/website-local.html#directory_layout thanks for this info as well... Regards, Dave -- MzK If you can keep your head when all others around you are losing theirs - maybe you don't fully understand the situation! -- Unknown
Re: How to handle the downloads?
Am 08/03/2011 04:54 PM, schrieb Andy Brown: Marcus (OOo) wrote: I've created a little diagram how I think the download has to work: http://incubator.apache.org/openofficeorg/docs/download_process.png As it seems we cannot go on like we did with OOo the JS magic has to change a bit, how to recognize the language, OS and country to assemble the nearest mirror server + file name to get the download URL. Marcus Marcus, One thing I would like to ask. That the user _not_ be offered a file that does not exist. We both saw that with the OOo system to many times. From non-existent with JRE plus language to versions for Blackberry. Andy For the case of an unavailable mirror I've added the File exists on mirror? box. Here the non-exisiting URL should be catched and exchanged with a working one. But for the special things like OOo on Blackberry we need to catch such kind of impossibilities earlier. Maybe right after the user agent was read and it's clear if it's for Windows, Linux, Mac, Solaris or indeed something different. Thanks for the hint. Marcus
Re: How to handle the downloads?
Marcus (OOo) wrote: Am 08/03/2011 04:54 PM, schrieb Andy Brown: Marcus (OOo) wrote: I've created a little diagram how I think the download has to work: http://incubator.apache.org/openofficeorg/docs/download_process.png As it seems we cannot go on like we did with OOo the JS magic has to change a bit, how to recognize the language, OS and country to assemble the nearest mirror server + file name to get the download URL. Marcus Marcus, One thing I would like to ask. That the user _not_ be offered a file that does not exist. We both saw that with the OOo system to many times. From non-existent with JRE plus language to versions for Blackberry. Andy For the case of an unavailable mirror I've added the File exists on mirror? box. Here the non-exisiting URL should be catched and exchanged with a working one. But for the special things like OOo on Blackberry we need to catch such kind of impossibilities earlier. Maybe right after the user agent was read and it's clear if it's for Windows, Linux, Mac, Solaris or indeed something different. Thanks for the hint. Marcus Just trying to prevent known problems from happening again. Andy
Re: How to handle the downloads?
On 3 August 2011 16:16, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 08/03/2011 04:57 PM, schrieb Ross Gardler: ... If that's the case then ignore my mail. Hm, not really, as we could bring together both magics into one process. OH, that bit is easy the choose mirror part of your JS Magic would request info from the existing mirror CGI code (might need some tweaks to provide the data in a usable form, but I'm sure infra@ are happy to help there once requirements are clear). Ross -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: How to handle the downloads?
Hi Marcus, This is really good. I've updated the diagram with more details and divided it into a 3-way-method: Download Choice #1: Of course the One-Click-Download URL. Download Choice #2: If an install file is available (wrong OS, no language, etc.) the user can select from a pre-defined list. Download Choice #3: The user can search for himself the most appropriate mirror server. Essentially with a little JS magic we will choose between three different download pages. I think that the download/index.html page should show text about what is being identified and then an indication that a load to go to #2 or #3 is happening and why. If there is a delay of 10 seconds the user might want to choose #2 or #3 automatically. And of course as now #2 and #3 are choices from the right side navigation. Regards, Dave Marcus Am 08/03/2011 05:54 PM, schrieb Andy Brown: Marcus (OOo) wrote: Am 08/03/2011 04:54 PM, schrieb Andy Brown: Marcus (OOo) wrote: I've created a little diagram how I think the download has to work: http://incubator.apache.org/openofficeorg/docs/download_process.png As it seems we cannot go on like we did with OOo the JS magic has to change a bit, how to recognize the language, OS and country to assemble the nearest mirror server + file name to get the download URL. Marcus Marcus, One thing I would like to ask. That the user _not_ be offered a file that does not exist. We both saw that with the OOo system to many times. From non-existent with JRE plus language to versions for Blackberry. Andy For the case of an unavailable mirror I've added the File exists on mirror? box. Here the non-exisiting URL should be catched and exchanged with a working one. But for the special things like OOo on Blackberry we need to catch such kind of impossibilities earlier. Maybe right after the user agent was read and it's clear if it's for Windows, Linux, Mac, Solaris or indeed something different. Thanks for the hint. Marcus Just trying to prevent known problems from happening again. Andy
Re: How to handle the downloads?
Am 08/03/2011 08:22 PM, schrieb Dave Fisher: Hi Marcus, This is really good. I've updated the diagram with more details and divided it into a 3-way-method: Download Choice #1: Of course the One-Click-Download URL. Download Choice #2: If an install file is not available (wrong OS, no language, etc.) the user can select from a pre-defined list. Download Choice #3: The user can search for himself the most appropriate mirror server. Essentially with a little JS magic we will choose between three different download pages. Ahm, not completely. You have to see the first 2 methods in the given order. I've corrected a missing not in the quote above. Only when #1 doesn't provide a working URL (the users should get notified about this fact, yes) they get redirected to #2. #3 is indeed only reachable from the side navigation. Pointing users to the raw mirror server should be our last intention. I think that the download/index.html page should show text about what is being identified and then an indication that a load to go to #2 or #3 is happening and why. If there is a delay of 10 seconds the user might want to choose #2 or #3 automatically. Yes, currently in OOo project this works well. The browser data gets read and the OS and language is shown in the green downlod box. And for this combination a URL gets created. Unfortunatelly it's also possible to get a non-working URL and this results in a 404 page. We haven't finished the exception catching so far. But new project, new try. ;-) And of course as now #2 and #3 are choices from the right side navigation. Yes. Marcus Am 08/03/2011 05:54 PM, schrieb Andy Brown: Marcus (OOo) wrote: Am 08/03/2011 04:54 PM, schrieb Andy Brown: Marcus (OOo) wrote: I've created a little diagram how I think the download has to work: http://incubator.apache.org/openofficeorg/docs/download_process.png As it seems we cannot go on like we did with OOo the JS magic has to change a bit, how to recognize the language, OS and country to assemble the nearest mirror server + file name to get the download URL. Marcus Marcus, One thing I would like to ask. That the user _not_ be offered a file that does not exist. We both saw that with the OOo system to many times. From non-existent with JRE plus language to versions for Blackberry. Andy For the case of an unavailable mirror I've added the File exists on mirror? box. Here the non-exisiting URL should be catched and exchanged with a working one. But for the special things like OOo on Blackberry we need to catch such kind of impossibilities earlier. Maybe right after the user agent was read and it's clear if it's for Windows, Linux, Mac, Solaris or indeed something different. Thanks for the hint. Marcus Just trying to prevent known problems from happening again. Andy
RE: How to handle the downloads?
-Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 6:45 PM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Am 08/03/2011 02:17 AM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 9:40 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Am 08/02/2011 11:03 PM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 12:55 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Thanks for you note. Then we should implement adownload method withthe fllowing order: 1. User clicks on the One-Click-Download URL and get the software (like today on download.openoffice.org). 2. If not, he can use alternative download links (like today on download.openoffice.org/pther.html). 3. If a special mirror has to be used, the list of all available mirrors will help (like today on http://distribution.openoffice.org/mirrors/#mirrors;). Latest with step 3 all users should be able to download something. Yep, all possible here at the ASF right now. See www.apache.org/mirrors for our equiv of step 3. I've already understood that you don't want the OOo mirrors but that we should use the Apache ones. ;-) Hi Marcus, don't count me as 100% on that yet, I want to know more about the OOo mirrors too. OK, if you have already questions just ask and I will try to give answers. not yet, working on it, I just didn't want to be maintaining 150+ projects on one mirror system and 1 project on another mirror system. maintaining one mirror system is easier, so If that is possible and our mirroring system can cope, and we can maybe coax a few more mirrors our way all the better. Some of our existing mirrors may decide that bandwidth is too much and leave, so we need replacements. I don't know about bandwidth but to get an impression about size and amount please have a look here. This mirror has rsync'ed everything that was released by Sun and Oracle: http://ftp5.gwdg.de/pub/openoffice/ thanks, If it makes sense to try and merge these somehow, I want to pursue that avenue. A first step should be to look for doubles. yep, We may need both for some time, we can not put non ASF releases on our mirroring system anyway so what we are trying to resolve is from our first ASF release onwards. Hm, when looking at this mirror it is already hosting non-Apache software: ftp://ftp.uni-erlangen.de/pub/mirrors/ Software from Apache and, e.g., OpenOffice.org is just a subset within many other projects. Sorry, that isn't what I meant. The mirrors get their content from us right, we can not provide them with non-asf released software to put on their mirror copy of our dist tree [1] . They are of course welcome to provide non-asf mirrors as most of them already do. [1] - http://apache.org/dist/ Gav... Marcus Am 08/02/2011 04:38 PM, schrieb Donald Whytock: A consideration...I for one have a need to be able to select my mirror. My office's firewall blocks certain domains and websites, especially those recognized as hosting or file-sharing sites. It does not, however, block .edu sites, so when I download an Apache product I select a university mirror. Other users may have similar constraints. If OOo's download process is going to tie into Apache mirroring, please don't completely eliminate the capacity to select the mirror. Don
RE: How to handle the downloads?
-Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Thursday, 4 August 2011 8:54 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Am 08/04/2011 12:38 AM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 6:45 PM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Am 08/03/2011 02:17 AM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 9:40 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Am 08/02/2011 11:03 PM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 12:55 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Thanks for you note. Then we should implement adownload method withthe fllowing order: 1. User clicks on the One-Click-Download URL and get the software (like today on download.openoffice.org). 2. If not, he can use alternative download links (like today on download.openoffice.org/pther.html). 3. If a special mirror has to be used, the list of all available mirrors will help (like today on http://distribution.openoffice.org/mirrors/#mirrors;). Latest with step 3 all users should be able to download something. Yep, all possible here at the ASF right now. See www.apache.org/mirrors for our equiv of step 3. I've already understood that you don't want the OOo mirrors but that we should use the Apache ones. ;-) Hi Marcus, don't count me as 100% on that yet, I want to know more about the OOo mirrors too. OK, if you have already questions just ask and I will try to give answers. not yet, working on it, I just didn't want to be maintaining 150+ projects on one mirror system and 1 project on another mirror system. maintaining one mirror system is easier, so If that is possible and our mirroring system can cope, and we can maybe coax a few more mirrors our way all the better. Some of our existing mirrors may decide that bandwidth is too much and leave, so we need replacements. I don't know about bandwidth but to get an impression about size and amount please have a look here. This mirror has rsync'ed everything that was released by Sun and Oracle: http://ftp5.gwdg.de/pub/openoffice/ thanks, If it makes sense to try and merge these somehow, I want to pursue that avenue. A first step should be to look for doubles. yep, We may need both for some time, we can not put non ASF releases on our mirroring system anyway so what we are trying to resolve is from our first ASF release onwards. Hm, when looking at this mirror it is already hosting non-Apache software: ftp://ftp.uni-erlangen.de/pub/mirrors/ Software from Apache and, e.g., OpenOffice.org is just a subset within many other projects. Sorry, that isn't what I meant. The mirrors get their content from us right, we can not provide them with non-asf released software to put on their mirror copy of our dist tree [1] . They are of course welcome to provide non-asf mirrors as most of them already do. [1] - http://apache.org/dist/ Gav... OK, let me try again. The mirrors can distribute what ever they want but within the Apache subdirs only ASF licensed software is allowed. Have a got it right now? Spot on. And the only way non ASF licenses software will get into the Apache subdirs is if we put it there in the first place. A project makes a release and puts the files of that release into a specific area of svn. That then syncs up with our main dist area, mirrors then sync up from there. IOW, the pre-existing mirror system for OOo needs to continue and be referred to in documentation and 'older releases' page so that folks can get pre-asf released versions of OOo from there. Only new releases from now onwards developed here at ASF will be put into our release/dist areas. HTH Gav... Marcus Am 08/02/2011 04:38 PM, schrieb Donald Whytock: A consideration...I for one have a need to be able to select my mirror. My office's firewall blocks certain domains and websites, especially those recognized as hosting or file-sharing sites. It does not, however, block .edu sites, so when I download an Apache product I select a university mirror. Other users may have similar constraints. If OOo's download process is going to tie into Apache mirroring, please don't completely eliminate the capacity to select the mirror. Don
Re: How to handle the downloads?
Am 08/02/2011 03:00 AM, schrieb Dave Fisher: On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote: Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. I have a script for downloading the download web source from the kenai svn. If I download the complete AOOo svn tree particularly ooo/trunk/tools/dev/fetch-all-web.sh You can run that script like so: $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt . You then get this (along with all the sub-projects in the web-list.txt) download dave$ ls -1 2.4.3 all_beta.html all_rc.html cachedimages common contribute.html download.js download2.js download_bouncer.js download_mirrorbrain.js exceptions.css globalvars.js index.html languages.js md5sums next notes.html other.html print_tables.js robots.txt sdk sdk.html source stable.html test So it's there and it is a matter of wrapping it properly. I don't know what you mean with wrapping. It's working and with adjustment of CSS (header, footer, graphics, etc.) and underlaying mirror structure it should run also for Apache. Should we start by committing the download site as a subsite of our incubator project? The websites inside the incubator project should be developer-oriented. But the download is nearly 100% user-related, so I would like to see this content to be continued on www.openoffice.org and not directly in a Apache domain. At least this separation will be established from my point of view. Marcus We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus
Re: How to handle the downloads?
On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 08/02/2011 03:00 AM, schrieb Dave Fisher: On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote: Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. I have a script for downloading the download web source from the kenai svn. If I download the complete AOOo svn tree particularly ooo/trunk/tools/dev/fetch-all-web.sh You can run that script like so: $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt . You then get this (along with all the sub-projects in the web-list.txt) download dave$ ls -1 2.4.3 all_beta.html all_rc.html cachedimages common contribute.html download.js download2.js download_bouncer.js download_mirrorbrain.js exceptions.css globalvars.js index.html languages.js md5sums next notes.html other.html print_tables.js robots.txt sdk sdk.html source stable.html test So it's there and it is a matter of wrapping it properly. I don't know what you mean with wrapping. It's working and with adjustment of CSS (header, footer, graphics, etc.) and underlaying mirror structure it should run also for Apache. Should we start by committing the download site as a subsite of our incubator project? The websites inside the incubator project should be developer-oriented. But the download is nearly 100% user-related, so I would like to see this content to be continued on www.openoffice.org and not directly in a Apache domain. I think the point is this: Even as we preserve the content of the OpenOffice.org website, we're not going to be re-hosting the Mercurial repositories on OO.o. Everything that was formerly in Mercurial will need to migrate somewhere else, either SVN at Apache or to Hg at Apache-Extras. The future OO.o website, hosted by Apache will have its source files checked into SVN at Apache. We'd have a mechanism to publish these files, on modification, to the right directory for the web server. We'll need a directory structure in SVN that reflects the fact that we'll be storing source files for two websites there. This is not hard. At least this separation will be established from my point of view. Marcus We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus
Re: How to handle the downloads?
A consideration...I for one have a need to be able to select my mirror. My office's firewall blocks certain domains and websites, especially those recognized as hosting or file-sharing sites. It does not, however, block .edu sites, so when I download an Apache product I select a university mirror. Other users may have similar constraints. If OOo's download process is going to tie into Apache mirroring, please don't completely eliminate the capacity to select the mirror. Don
Re: How to handle the downloads?
On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote: Am 08/02/2011 02:15 PM, schrieb Rob Weir: On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 03:00 AM, schrieb Dave Fisher: On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote: Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. I have a script for downloading the download web source from the kenai svn. If I download the complete AOOo svn tree particularly ooo/trunk/tools/dev/fetch-all-web.sh You can run that script like so: $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt . You then get this (along with all the sub-projects in the web-list.txt) download dave$ ls -1 2.4.3 all_beta.html all_rc.html cachedimages common contribute.html download.js download2.js download_bouncer.js download_mirrorbrain.js exceptions.css globalvars.js index.html languages.js md5sums next notes.html other.html print_tables.js robots.txt sdk sdk.html source stable.html test So it's there and it is a matter of wrapping it properly. I don't know what you mean with wrapping. It's working and with adjustment of CSS (header, footer, graphics, etc.) and underlaying mirror structure it should run also for Apache. Should we start by committing the download site as a subsite of our incubator project? The websites inside the incubator project should be developer-oriented. But the download is nearly 100% user-related, so I would like to see this content to be continued on www.openoffice.org and not directly in a Apache domain. I think the point is this: Even as we preserve the content of the OpenOffice.org website, we're not going to be re-hosting the Mercurial repositories on OO.o. Everything that was formerly in Mercurial will need to migrate somewhere else, either SVN at Apache or to Hg at Apache-Extras. The future OO.o website, hosted by Apache will have its source files checked into SVN at Apache. We'd have a mechanism to publish these files, on modification, to the right directory for the web server. We'll need a directory structure in SVN that reflects the fact that we'll be storing source files for two websites there. This is not hard. Right. In the SVN repo we have to make the separation of the 2 domains visible.' Yes that is very true, but there is a problem. We only have the one incubator site in the Apache CMS and we need to do some experimental conversions. Let's mix in with our Incubator site two initial projects - www and download - as subdirectories so we can get started with headers and footers and modifying the CMS build to handle the OOo site pages from Kenai. We can then get started with branding as well. Later we can change the svn structure to the one that allows publishing of multiple sites in Apache. We'll need to discuss the publishing of the openoffice domains using the Apache CMS with Infrastructure. Regards, Dave Marcus At least this separation will be established from my point of view. Marcus We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus
Re: How to handle the downloads?
Am 08/02/2011 04:53 PM, schrieb Dave Fisher: On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote: Am 08/02/2011 02:15 PM, schrieb Rob Weir: On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 03:00 AM, schrieb Dave Fisher: On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote: Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. I have a script for downloading the download web source from the kenai svn. If I download the complete AOOo svn tree particularly ooo/trunk/tools/dev/fetch-all-web.sh You can run that script like so: $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt . You then get this (along with all the sub-projects in the web-list.txt) download dave$ ls -1 2.4.3 all_beta.html all_rc.html cachedimages common contribute.html download.js download2.js download_bouncer.js download_mirrorbrain.js exceptions.css globalvars.js index.html languages.js md5sums next notes.html other.html print_tables.js robots.txt sdk sdk.html source stable.html test So it's there and it is a matter of wrapping it properly. I don't know what you mean with wrapping. It's working and with adjustment of CSS (header, footer, graphics, etc.) and underlaying mirror structure it should run also for Apache. Should we start by committing the download site as a subsite of our incubator project? The websites inside the incubator project should be developer-oriented. But the download is nearly 100% user-related, so I would like to see this content to be continued on www.openoffice.org and not directly in a Apache domain. I think the point is this: Even as we preserve the content of the OpenOffice.org website, we're not going to be re-hosting the Mercurial repositories on OO.o. Everything that was formerly in Mercurial will need to migrate somewhere else, either SVN at Apache or to Hg at Apache-Extras. The future OO.o website, hosted by Apache will have its source files checked into SVN at Apache. We'd have a mechanism to publish these files, on modification, to the right directory for the web server. We'll need a directory structure in SVN that reflects the fact that we'll be storing source files for two websites there. This is not hard. Right. In the SVN repo we have to make the separation of the 2 domains visible.' Yes that is very true, but there is a problem. We only have the one incubator site in the Apache CMS and we need to do some experimental conversions. Let's mix in with our Incubator site two initial projects - www and download - as subdirectories so we can get started with headers and footers and modifying the CMS build to handle the OOo site pages from Kenai. OK, no problem to migratethe webpages into the incubator project. Tehn we can play a bit with the content to see how it behaves. We can then get started with branding as well. Later we can change the svn structure to the one that allows publishing of multiple sites in Apache. We'll need to discuss the publishing of the openoffice domains using the Apache CMS with Infrastructure. +1 Marcus At least this separation will be established from my point of view. Marcus We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus
Re: How to handle the downloads?
On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote: Am 08/02/2011 04:53 PM, schrieb Dave Fisher: On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote: Am 08/02/2011 02:15 PM, schrieb Rob Weir: On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 03:00 AM, schrieb Dave Fisher: On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote: Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. I have a script for downloading the download web source from the kenai svn. If I download the complete AOOo svn tree particularly ooo/trunk/tools/dev/fetch-all-web.sh You can run that script like so: $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt . You then get this (along with all the sub-projects in the web-list.txt) download dave$ ls -1 2.4.3 all_beta.html all_rc.html cachedimages common contribute.html download.js download2.js download_bouncer.js download_mirrorbrain.js exceptions.css globalvars.js index.html languages.js md5sums next notes.html other.html print_tables.js robots.txt sdk sdk.html source stable.html test So it's there and it is a matter of wrapping it properly. I don't know what you mean with wrapping. It's working and with adjustment of CSS (header, footer, graphics, etc.) and underlaying mirror structure it should run also for Apache. Should we start by committing the download site as a subsite of our incubator project? The websites inside the incubator project should be developer-oriented. But the download is nearly 100% user-related, so I would like to see this content to be continued on www.openoffice.org and not directly in a Apache domain. I think the point is this: Even as we preserve the content of the OpenOffice.org website, we're not going to be re-hosting the Mercurial repositories on OO.o. Everything that was formerly in Mercurial will need to migrate somewhere else, either SVN at Apache or to Hg at Apache-Extras. The future OO.o website, hosted by Apache will have its source files checked into SVN at Apache. We'd have a mechanism to publish these files, on modification, to the right directory for the web server. We'll need a directory structure in SVN that reflects the fact that we'll be storing source files for two websites there. This is not hard. Right. In the SVN repo we have to make the separation of the 2 domains visible.' Yes that is very true, but there is a problem. We only have the one incubator site in the Apache CMS and we need to do some experimental conversions. Let's mix in with our Incubator site two initial projects - www and download - as subdirectories so we can get started with headers and footers and modifying the CMS build to handle the OOo site pages from Kenai. OK, no problem to migratethe webpages into the incubator project. Tehn we can play a bit with the content to see how it behaves. We can then get started with branding as well. Later we can change the svn structure to the one that allows publishing of multiple sites in Apache. We'll need to discuss the publishing of the openoffice domains using the Apache CMS with Infrastructure. +1 I have committed the download project to the AOOo svn. No headers and footers yet, but it is now available for play http://incubator.apache.org/openofficeorg/download/index.html To get headers and footers a template is needed and the view.pm will need adjustment. See http://incubator.apache.org/openofficeorg/website-local.html#directory_layout Regards, Dave Marcus At least this separation will be established from my point of view. Marcus We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus
Re: How to handle the downloads?
Am 08/02/2011 06:05 PM, schrieb Dave Fisher: On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote: Am 08/02/2011 04:53 PM, schrieb Dave Fisher: On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote: Am 08/02/2011 02:15 PM, schrieb Rob Weir: On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)marcus.m...@wtnet.dewrote: Am 08/02/2011 03:00 AM, schrieb Dave Fisher: On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote: Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. I have a script for downloading the download web source from the kenai svn. If I download the complete AOOo svn tree particularly ooo/trunk/tools/dev/fetch-all-web.sh You can run that script like so: $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt . You then get this (along with all the sub-projects in the web-list.txt) download dave$ ls -1 2.4.3 all_beta.html all_rc.html cachedimages common contribute.html download.js download2.js download_bouncer.js download_mirrorbrain.js exceptions.css globalvars.js index.html languages.js md5sums next notes.html other.html print_tables.js robots.txt sdk sdk.html source stable.html test So it's there and it is a matter of wrapping it properly. I don't know what you mean with wrapping. It's working and with adjustment of CSS (header, footer, graphics, etc.) and underlaying mirror structure it should run also for Apache. Should we start by committing the download site as a subsite of our incubator project? The websites inside the incubator project should be developer-oriented. But the download is nearly 100% user-related, so I would like to see this content to be continued on www.openoffice.org and not directly in a Apache domain. I think the point is this: Even as we preserve the content of the OpenOffice.org website, we're not going to be re-hosting the Mercurial repositories on OO.o. Everything that was formerly in Mercurial will need to migrate somewhere else, either SVN at Apache or to Hg at Apache-Extras. The future OO.o website, hosted by Apache will have its source files checked into SVN at Apache. We'd have a mechanism to publish these files, on modification, to the right directory for the web server. We'll need a directory structure in SVN that reflects the fact that we'll be storing source files for two websites there. This is not hard. Right. In the SVN repo we have to make the separation of the 2 domains visible.' Yes that is very true, but there is a problem. We only have the one incubator site in the Apache CMS and we need to do some experimental conversions. Let's mix in with our Incubator site two initial projects - www and download - as subdirectories so we can get started with headers and footers and modifying the CMS build to handle the OOo site pages from Kenai. OK, no problem to migratethe webpages into the incubator project. Tehn we can play a bit with the content to see how it behaves. We can then get started with branding as well. Later we can change the svn structure to the one that allows publishing of multiple sites in Apache. We'll need to discuss the publishing of the openoffice domains using the Apache CMS with Infrastructure. +1 I have committed the download project to the AOOo svn. No headers and footers yet, but it is now available for play http://incubator.apache.org/openofficeorg/download/index.html To get headers and footers a template is needed and the view.pm will need adjustment. See http://incubator.apache.org/openofficeorg/website-local.html#directory_layout The nice CSS styling was was done somehow bekind the Kenai framework. Not that easy to find all that stuff and to re-implement the basics. But let's see... Thanks for your fast commit. :-) Marcus At least this separation will be established from my point of view. Marcus We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus
Re: How to handle the downloads?
On 08/02/2011 09:05 AM, Dave Fisher wrote: On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote: Am 08/02/2011 04:53 PM, schrieb Dave Fisher: On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote: Am 08/02/2011 02:15 PM, schrieb Rob Weir: On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)marcus.m...@wtnet.dewrote: Am 08/02/2011 03:00 AM, schrieb Dave Fisher: On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote: Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. I have a script for downloading the download web source from the kenai svn. If I download the complete AOOo svn tree particularly ooo/trunk/tools/dev/fetch-all-web.sh You can run that script like so: $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt . You then get this (along with all the sub-projects in the web-list.txt) download dave$ ls -1 2.4.3 all_beta.html all_rc.html cachedimages common contribute.html download.js download2.js download_bouncer.js download_mirrorbrain.js exceptions.css globalvars.js index.html languages.js md5sums next notes.html other.html print_tables.js robots.txt sdk sdk.html source stable.html test So it's there and it is a matter of wrapping it properly. I don't know what you mean with wrapping. It's working and with adjustment of CSS (header, footer, graphics, etc.) and underlaying mirror structure it should run also for Apache. Should we start by committing the download site as a subsite of our incubator project? The websites inside the incubator project should be developer-oriented. But the download is nearly 100% user-related, so I would like to see this content to be continued on www.openoffice.org and not directly in a Apache domain. I think the point is this: Even as we preserve the content of the OpenOffice.org website, we're not going to be re-hosting the Mercurial repositories on OO.o. Everything that was formerly in Mercurial will need to migrate somewhere else, either SVN at Apache or to Hg at Apache-Extras. The future OO.o website, hosted by Apache will have its source files checked into SVN at Apache. We'd have a mechanism to publish these files, on modification, to the right directory for the web server. We'll need a directory structure in SVN that reflects the fact that we'll be storing source files for two websites there. This is not hard. Right. In the SVN repo we have to make the separation of the 2 domains visible.' Yes that is very true, but there is a problem. We only have the one incubator site in the Apache CMS and we need to do some experimental conversions. Let's mix in with our Incubator site two initial projects - www and download - as subdirectories so we can get started with headers and footers and modifying the CMS build to handle the OOo site pages from Kenai. OK, no problem to migratethe webpages into the incubator project. Tehn we can play a bit with the content to see how it behaves. We can then get started with branding as well. Later we can change the svn structure to the one that allows publishing of multiple sites in Apache. We'll need to discuss the publishing of the openoffice domains using the Apache CMS with Infrastructure. +1 I have committed the download project to the AOOo svn. No headers and footers yet, but it is now available for play http://incubator.apache.org/openofficeorg/download/index.html good start! To get headers and footers a template is needed and the view.pm will need adjustment. See http://incubator.apache.org/openofficeorg/website-local.html#directory_layout Regards, Dave Marcus At least this separation will be established from my point of view. Marcus We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus -- MzK If you can keep your head when all others around you are losing theirs - maybe you don't fully understand the situation! -- Unknown
Re: How to handle the downloads?
Kay, On Aug 2, 2011, at 11:43 AM, Kay Schenk wrote: On 08/02/2011 09:05 AM, Dave Fisher wrote: On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote: Am 08/02/2011 04:53 PM, schrieb Dave Fisher: On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote: Am 08/02/2011 02:15 PM, schrieb Rob Weir: On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)marcus.m...@wtnet.dewrote: Am 08/02/2011 03:00 AM, schrieb Dave Fisher: On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote: Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. I have a script for downloading the download web source from the kenai svn. If I download the complete AOOo svn tree particularly ooo/trunk/tools/dev/fetch-all-web.sh You can run that script like so: $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt . You then get this (along with all the sub-projects in the web-list.txt) download dave$ ls -1 2.4.3 all_beta.html all_rc.html cachedimages common contribute.html download.js download2.js download_bouncer.js download_mirrorbrain.js exceptions.css globalvars.js index.html languages.js md5sums next notes.html other.html print_tables.js robots.txt sdk sdk.html source stable.html test So it's there and it is a matter of wrapping it properly. I don't know what you mean with wrapping. It's working and with adjustment of CSS (header, footer, graphics, etc.) and underlaying mirror structure it should run also for Apache. Should we start by committing the download site as a subsite of our incubator project? The websites inside the incubator project should be developer-oriented. But the download is nearly 100% user-related, so I would like to see this content to be continued on www.openoffice.org and not directly in a Apache domain. I think the point is this: Even as we preserve the content of the OpenOffice.org website, we're not going to be re-hosting the Mercurial repositories on OO.o. Everything that was formerly in Mercurial will need to migrate somewhere else, either SVN at Apache or to Hg at Apache-Extras. The future OO.o website, hosted by Apache will have its source files checked into SVN at Apache. We'd have a mechanism to publish these files, on modification, to the right directory for the web server. We'll need a directory structure in SVN that reflects the fact that we'll be storing source files for two websites there. This is not hard. Right. In the SVN repo we have to make the separation of the 2 domains visible.' Yes that is very true, but there is a problem. We only have the one incubator site in the Apache CMS and we need to do some experimental conversions. Let's mix in with our Incubator site two initial projects - www and download - as subdirectories so we can get started with headers and footers and modifying the CMS build to handle the OOo site pages from Kenai. OK, no problem to migratethe webpages into the incubator project. Tehn we can play a bit with the content to see how it behaves. We can then get started with branding as well. Later we can change the svn structure to the one that allows publishing of multiple sites in Apache. We'll need to discuss the publishing of the openoffice domains using the Apache CMS with Infrastructure. +1 I have committed the download project to the AOOo svn. No headers and footers yet, but it is now available for play http://incubator.apache.org/openofficeorg/download/index.html good start! http://incubator.apache.org/openofficeorg/www/index.html Will be there soon. I think I committed more at once than I should. There is a lot of deadwood there that should be removed. Regards, Dave To get headers and footers a template is needed and the view.pm will need adjustment. See http://incubator.apache.org/openofficeorg/website-local.html#directory_layout Regards, Dave Marcus At least this separation will be established from my point of view. Marcus We still need someone to work with infra@ to ensure the mirror network can cope with the load, but I'm sure that will be handled in good time. Marcus -- MzK If you can keep your head when all others around you are losing theirs - maybe you don't fully understand the situation! -- Unknown
RE: How to handle the downloads?
-Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 12:55 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Thanks for you note. Then we should implement adownload method withthe fllowing order: 1. User clicks on the One-Click-Download URL and get the software (like today on download.openoffice.org). 2. If not, he can use alternative download links (like today on download.openoffice.org/pther.html). 3. If a special mirror has to be used, the list of all available mirrors will help (like today on http://distribution.openoffice.org/mirrors/#mirrors;). Latest with step 3 all users should be able to download something. Yep, all possible here at the ASF right now. See www.apache.org/mirrors for our equiv of step 3. Gav... Marcus Am 08/02/2011 04:38 PM, schrieb Donald Whytock: A consideration...I for one have a need to be able to select my mirror. My office's firewall blocks certain domains and websites, especially those recognized as hosting or file-sharing sites. It does not, however, block .edu sites, so when I download an Apache product I select a university mirror. Other users may have similar constraints. If OOo's download process is going to tie into Apache mirroring, please don't completely eliminate the capacity to select the mirror. Don
Re: How to handle the downloads?
A use case to consider, for future possibilities. What would be required to do this well, not from a web page, but inside the OpenOffice application? So patches, extensions, templates, even upgrades initiated from within the app itself, without launching a browser? Is that doable? If the geo location is done via IP address, and there is a REST API for finding the closest mirrors, and that returns data in XML or JSON, that it should be universally consumable. -Rob On Tue, Aug 2, 2011 at 4:45 PM, Dave Fisher dave2w...@comcast.net wrote: Kay, On Aug 2, 2011, at 11:43 AM, Kay Schenk wrote: On 08/02/2011 09:05 AM, Dave Fisher wrote: On Aug 2, 2011, at 8:06 AM, Marcus (OOo) wrote: Am 08/02/2011 04:53 PM, schrieb Dave Fisher: On Aug 2, 2011, at 7:27 AM, Marcus (OOo) wrote: Am 08/02/2011 02:15 PM, schrieb Rob Weir: On Tue, Aug 2, 2011 at 4:03 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 03:00 AM, schrieb Dave Fisher: On Aug 1, 2011, at 4:34 PM, Marcus (OOo) wrote: Am 08/02/2011 01:00 AM, schrieb Ross Gardler: On 1 August 2011 23:42, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: ... The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Why don't you mock-up 9in the CMS) what you want the download page to look like, without linking it in from elsewhere. Once that is done then we can look at making the download.cgi work the way you want it. Good idea. Will do so. I have a script for downloading the download web source from the kenai svn. If I download the complete AOOo svn tree particularly ooo/trunk/tools/dev/fetch-all-web.sh You can run that script like so: $ ../trunk/tools/dev/fetch-all-web.sh ../trunk/tools/dev/web-list.txt . You then get this (along with all the sub-projects in the web-list.txt) download dave$ ls -1 2.4.3 all_beta.html all_rc.html cachedimages common contribute.html download.js download2.js download_bouncer.js download_mirrorbrain.js exceptions.css globalvars.js index.html languages.js md5sums next notes.html other.html print_tables.js robots.txt sdk sdk.html source stable.html test So it's there and it is a matter of wrapping it properly. I don't know what you mean with wrapping. It's working and with adjustment of CSS (header, footer, graphics, etc.) and underlaying mirror structure it should run also for Apache. Should we start by committing the download site as a subsite of our incubator project? The websites inside the incubator project should be developer-oriented. But the download is nearly 100% user-related, so I would like to see this content to be continued on www.openoffice.org and not directly in a Apache domain. I think the point is this: Even as we preserve the content of the OpenOffice.org website, we're not going to be re-hosting the Mercurial repositories on OO.o. Everything that was formerly in Mercurial will need to migrate somewhere else, either SVN at Apache or to Hg at Apache-Extras. The future OO.o website, hosted by Apache will have its source files checked into SVN at Apache. We'd have a mechanism to publish these files, on modification, to the right directory for the web server. We'll need a directory structure in SVN that reflects the fact that we'll be storing source files for two websites there. This is not hard. Right. In the SVN repo we have to make the separation of the 2 domains visible.' Yes that is very true, but there is a problem. We only have the one incubator site in the Apache CMS and we need to do some experimental conversions. Let's mix in with our Incubator site two initial projects - www and download - as subdirectories so we can get started with headers and footers and modifying the CMS build to handle the OOo site pages from Kenai. OK, no problem to migratethe webpages into the incubator project. Tehn we can play a bit with the content to see how it behaves. We can then get started with branding as well. Later we can change the svn structure to the one that allows publishing of multiple sites in Apache. We'll need to discuss the publishing of the openoffice domains using the Apache CMS with Infrastructure. +1 I have committed the download project to the AOOo svn. No headers and footers yet, but it is now available for play http://incubator.apache.org/openofficeorg/download/index.html good start! http://incubator.apache.org/openofficeorg/www/index.html Will be there soon. I think I committed more at once than I should. There is a lot of deadwood there that should be removed. Regards, Dave To get headers and footers a template is needed and the view.pm will need adjustment. See http://incubator.apache.org/openofficeorg/website-local.html#directory_layout Regards, Dave Marcus
Re: How to handle the downloads?
Am 08/02/2011 11:03 PM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 12:55 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Thanks for you note. Then we should implement adownload method withthe fllowing order: 1. User clicks on the One-Click-Download URL and get the software (like today on download.openoffice.org). 2. If not, he can use alternative download links (like today on download.openoffice.org/pther.html). 3. If a special mirror has to be used, the list of all available mirrors will help (like today on http://distribution.openoffice.org/mirrors/#mirrors;). Latest with step 3 all users should be able to download something. Yep, all possible here at the ASF right now. See www.apache.org/mirrors for our equiv of step 3. I've already understood that you don't want the OOo mirrors but that we should use the Apache ones. ;-) Marcus Am 08/02/2011 04:38 PM, schrieb Donald Whytock: A consideration...I for one have a need to be able to select my mirror. My office's firewall blocks certain domains and websites, especially those recognized as hosting or file-sharing sites. It does not, however, block .edu sites, so when I download an Apache product I select a university mirror. Other users may have similar constraints. If OOo's download process is going to tie into Apache mirroring, please don't completely eliminate the capacity to select the mirror. Don
RE: How to handle the downloads?
-Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 9:40 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Am 08/02/2011 11:03 PM, schrieb Gavin McDonald: -Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Wednesday, 3 August 2011 12:55 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Thanks for you note. Then we should implement adownload method withthe fllowing order: 1. User clicks on the One-Click-Download URL and get the software (like today on download.openoffice.org). 2. If not, he can use alternative download links (like today on download.openoffice.org/pther.html). 3. If a special mirror has to be used, the list of all available mirrors will help (like today on http://distribution.openoffice.org/mirrors/#mirrors;). Latest with step 3 all users should be able to download something. Yep, all possible here at the ASF right now. See www.apache.org/mirrors for our equiv of step 3. I've already understood that you don't want the OOo mirrors but that we should use the Apache ones. ;-) Hi Marcus, don't count me as 100% on that yet, I want to know more about the OOo mirrors too. I just didn't want to be maintaining 150+ projects on one mirror system and 1 project on another mirror system. maintaining one mirror system is easier, so If that is possible and our mirroring system can cope, and we can maybe coax a few more mirrors our way all the better. Some of our existing mirrors may decide that bandwidth is too much and leave, so we need replacements. If it makes sense to try and merge these somehow, I want to pursue that avenue. We may need both for some time, we can not put non ASF releases on our mirroring system anyway so what we are trying to resolve is from our first ASF release onwards. Gav... Marcus Am 08/02/2011 04:38 PM, schrieb Donald Whytock: A consideration...I for one have a need to be able to select my mirror. My office's firewall blocks certain domains and websites, especially those recognized as hosting or file-sharing sites. It does not, however, block .edu sites, so when I download an Apache product I select a university mirror. Other users may have similar constraints. If OOo's download process is going to tie into Apache mirroring, please don't completely eliminate the capacity to select the mirror. Don
Re: How to handle the downloads?
On Mon, Aug 1, 2011 at 1:20 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Hi, AFAIK the current projects at Apache doesn't have high download numbers compared with OOo. So, a download request can point directly to a mirror or a mirror list is shown and the users have to choose themselves from where to get the software best. For OpenOffice this doesn't work. With download numbers up to 500,000 per month we need a more flexible and scaleable solution. I don't know if or how fast we could reach these numbers again. But even with the half it would be a lot to handle. Furthermore we have to present a) a simple way to download for the end-users that is b) *not* stressing a few/specific mirror servers to their maximum. The current solution you can see on download.openoffice.org works very well. However, the infrastructure behind this is still hosted on Oracle server. So, we have to transfer this, too. I don't speak about domain, website and its content. That's already on the list for migration. It's about the download redirector behind the colored webpages (http://download.services.openoffice.org/files/). Here MirrorBrain is used (www.mirrorbrain.org) to recognize from where the download request comes and which mirror server to choose that is near to the user. I would like to continue this service and IMHO it shouldn't be that difficult when I look at the requirements: http://www.mirrorbrain.org/requirements/ The obvious question would be: Is there a problem with using the 262 mirrors that Apache already uses? http://www.apache.org/mirrors/ Do you think that they cannot handle the load? From what I'm reading, the Apache system does not just give a static list of mirrors to the user. There is some logic to ensure that the same server is not at the top all the time. And there are mechanisms, like closer.cgi to suggest a reasonable mirror for a given user, e.g.: http://www.apache.org/dyn/closer.cgi I wonder whether it would make sense to try the Apache mirroring infrastructure until we're convinced that it won't work? When running in a VM it should be a small part within the OpenOffice project to maintain. In the past at Oracle we just had to add/modify/delete mirrors and very few times to restart the VM in case of problems. Marcus
Re: How to handle the downloads?
On Aug 1, 2011, at 12:07 PM, Rob Weir wrote: On Mon, Aug 1, 2011 at 1:20 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Hi, AFAIK the current projects at Apache doesn't have high download numbers compared with OOo. So, a download request can point directly to a mirror or a mirror list is shown and the users have to choose themselves from where to get the software best. For OpenOffice this doesn't work. With download numbers up to 500,000 per month we need a more flexible and scaleable solution. I don't know if or how fast we could reach these numbers again. But even with the half it would be a lot to handle. Furthermore we have to present a) a simple way to download for the end-users that is b) *not* stressing a few/specific mirror servers to their maximum. The current solution you can see on download.openoffice.org works very well. However, the infrastructure behind this is still hosted on Oracle server. So, we have to transfer this, too. I don't speak about domain, website and its content. That's already on the list for migration. It's about the download redirector behind the colored webpages (http://download.services.openoffice.org/files/). Here MirrorBrain is used (www.mirrorbrain.org) to recognize from where the download request comes and which mirror server to choose that is near to the user. I would like to continue this service and IMHO it shouldn't be that difficult when I look at the requirements: http://www.mirrorbrain.org/requirements/ The obvious question would be: Is there a problem with using the 262 mirrors that Apache already uses? Maybe, if we are hosting the current legacy of non AL2.0 licensed distributions it will be an issue. http://www.apache.org/mirrors/ Do you think that they cannot handle the load? From what I'm reading, the Apache system does not just give a static list of mirrors to the user. There is some logic to ensure that the same server is not at the top all the time. And there are mechanisms, like closer.cgi to suggest a reasonable mirror for a given user, e.g.: http://www.apache.org/dyn/closer.cgi I wonder whether it would make sense to try the Apache mirroring infrastructure until we're convinced that it won't work? The python for the Apache Mirrors is here: http://svn.apache.org/repos/asf/infrastructure/site/trunk/content/dyn/mirrors/mirrors.cgi Mirror list is here: http://www.apache.org/mirrors/mirrors.list Someone mentioned that there is a lot of overlap with OOo mirrors. Regards, Dave When running in a VM it should be a small part within the OpenOffice project to maintain. In the past at Oracle we just had to add/modify/delete mirrors and very few times to restart the VM in case of problems. Marcus
Re: How to handle the downloads?
On 1 August 2011 18:20, Marcus (OOo) marcus.m...@wtnet.de wrote: AFAIK the current projects at Apache doesn't have high download numbers compared with OOo. So, a download request can point directly to a mirror or a mirror list is shown and the users have to choose themselves from where to get the software best. I wouldn't make any assumptions about the current mirror infrastructure. What you write above does not reflect how things work here. The ASF is a pretty large collection of projects with some very large numbers behind it. Does anyone here have the precise requirements and implementation details of the existing mirror network? It would be really useful to document that and take it to the infra team who can then evaluate what changes, if any, need to be made to the existing system. Ross
Re: How to handle the downloads?
On 8/1/2011 5:51 PM, Marcus (OOo) wrote: Am 08/01/2011 09:25 PM, schrieb Ross Gardler: On 1 August 2011 18:20, Marcus (OOo)marcus.m...@wtnet.de wrote: AFAIK the current projects at Apache doesn't have high download numbers compared with OOo. So, a download request can point directly to a mirror or a mirror list is shown and the users have to choose themselves from where to get the software best. I wouldn't make any assumptions about the current mirror infrastructure. What you write above does not reflect how things work here. The ASF is a pretty large collection of projects with some very large numbers behind it. I've looked at this both pages: http://www.apache.org/dyn/closer.cgi http://httpd.apache.org/download.cgi When comparing it with the one from the current OOo project you should be able to see big differences: - too many links - too much data on one page - too much information to read to get an overview - too less clear structure There are two, mostly orthogonal issues to discuss here - which is why it's doubly important to better document what 1) features we think OOo needs on it's download pages, and 2) what software capacity is being used currently for OOo downloads on the Oracle infra. - Basic presentation of the download page. In most Apache projects, this can be controlled by the project. Thus we could better control the display of the physical download.cgi page itself within the Apache OOo project, to better explain to users what they want. - Implementation of mirror choosing on the download page. This is for someone from infra to discuss. Separately is how mirrors are managed and rsync'd, but I'm sure once we figure out the above parts there can be a plan for migrating (or adopting) the syncing to the mirrors. - Shane Please keep in mind that we have to deal with end-users. Maybe there are a lot of power-users but even they prefer a simple and straight solution. ;-) Marcus Does anyone here have the precise requirements and implementation details of the existing mirror network? It would be really useful to document that and take it to the infra team who can then evaluate what changes, if any, need to be made to the existing system.
Re: How to handle the downloads?
Am 08/01/2011 09:07 PM, schrieb Rob Weir: On Mon, Aug 1, 2011 at 1:20 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Hi, AFAIK the current projects at Apache doesn't have high download numbers compared with OOo. So, a download request can point directly to a mirror or a mirror list is shown and the users have to choose themselves from where to get the software best. For OpenOffice this doesn't work. With download numbers up to 500,000 per month we need a more flexible and scaleable solution. I don't know if or how fast we could reach these numbers again. But even with the half it would be a lot to handle. Furthermore we have to present a) a simple way to download for the end-users that is b) *not* stressing a few/specific mirror servers to their maximum. The current solution you can see on download.openoffice.org works very well. However, the infrastructure behind this is still hosted on Oracle server. So, we have to transfer this, too. I don't speak about domain, website and its content. That's already on the list for migration. It's about the download redirector behind the colored webpages (http://download.services.openoffice.org/files/). Here MirrorBrain is used (www.mirrorbrain.org) to recognize from where the download request comes and which mirror server to choose that is near to the user. I would like to continue this service and IMHO it shouldn't be that difficult when I look at the requirements: http://www.mirrorbrain.org/requirements/ The obvious question would be: Is there a problem with using the 262 mirrors that Apache already uses? http://www.apache.org/mirrors/ Do you think that they cannot handle the load? That's not the question. Otherwise I could present this list: http://distribution.openoffice.org/mirrors/#mirrors ;-) No, the real question is not the load but how to do the load balancing and how to present the best download link to the user. From what I'm reading, the Apache system does not just give a static list of mirrors to the user. There is some logic to ensure that the same server is not at the top all the time. And there are mechanisms, like closer.cgi to suggest a reasonable mirror for a given user, e.g.: http://www.apache.org/dyn/closer.cgi Maybe it's a pre-chosen thing to present a download link. But still it's a list of servers the user has to choose on there own. And only after they have seen that only the first link is the pre-chosen one and the others are nice to know. ;-) For me it's not clear enough. I wonder whether it would make sense to try the Apache mirroring infrastructure until we're convinced that it won't work? Depends on what you define here with working. Technically it will work. Maybe Apache will ? a bit because of the suddenly increased load (when we switch the download method from one to the other day). But the user hasn't a good solution when searching for a download. See my answer to Ross. When running in a VM it should be a small part within the OpenOffice project to maintain. In the past at Oracle we just had to add/modify/delete mirrors and very few times to restart the VM in case of problems. Marcus Marcus
Re: How to handle the downloads?
Am 08/01/2011 09:14 PM, schrieb Dave Fisher: On Aug 1, 2011, at 12:07 PM, Rob Weir wrote: On Mon, Aug 1, 2011 at 1:20 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Hi, AFAIK the current projects at Apache doesn't have high download numbers compared with OOo. So, a download request can point directly to a mirror or a mirror list is shown and the users have to choose themselves from where to get the software best. For OpenOffice this doesn't work. With download numbers up to 500,000 per month we need a more flexible and scaleable solution. I don't know if or how fast we could reach these numbers again. But even with the half it would be a lot to handle. Furthermore we have to present a) a simple way to download for the end-users that is b) *not* stressing a few/specific mirror servers to their maximum. The current solution you can see on download.openoffice.org works very well. However, the infrastructure behind this is still hosted on Oracle server. So, we have to transfer this, too. I don't speak about domain, website and its content. That's already on the list for migration. It's about the download redirector behind the colored webpages (http://download.services.openoffice.org/files/). Here MirrorBrain is used (www.mirrorbrain.org) to recognize from where the download request comes and which mirror server to choose that is near to the user. I would like to continue this service and IMHO it shouldn't be that difficult when I look at the requirements: http://www.mirrorbrain.org/requirements/ The obvious question would be: Is there a problem with using the 262 mirrors that Apache already uses? Maybe, if we are hosting the current legacy of non AL2.0 licensed distributions it will be an issue. http://www.apache.org/mirrors/ Do you think that they cannot handle the load? From what I'm reading, the Apache system does not just give a static list of mirrors to the user. There is some logic to ensure that the same server is not at the top all the time. And there are mechanisms, like closer.cgi to suggest a reasonable mirror for a given user, e.g.: http://www.apache.org/dyn/closer.cgi I wonder whether it would make sense to try the Apache mirroring infrastructure until we're convinced that it won't work? The python for the Apache Mirrors is here: http://svn.apache.org/repos/asf/infrastructure/site/trunk/content/dyn/mirrors/mirrors.cgi Mirror list is here: http://www.apache.org/mirrors/mirrors.list Someone mentioned that there is a lot of overlap with OOo mirrors. IMHO the problem is not the number or structure of the mirror network. Of course we can use the mirror server for Apache. But the how to use them is important. Marcus When running in a VM it should be a small part within the OpenOffice project to maintain. In the past at Oracle we just had to add/modify/delete mirrors and very few times to restart the VM in case of problems. Marcus
Re: How to handle the downloads?
Am 08/02/2011 12:15 AM, schrieb Ross Gardler: On 1 August 2011 22:51, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/01/2011 09:25 PM, schrieb Ross Gardler: On 1 August 2011 18:20, Marcus (OOo)marcus.m...@wtnet.dewrote: AFAIK the current projects at Apache doesn't have high download numbers compared with OOo. So, a download request can point directly to a mirror or a mirror list is shown and the users have to choose themselves from where to get the software best. I wouldn't make any assumptions about the current mirror infrastructure. What you write above does not reflect how things work here. The ASF is a pretty large collection of projects with some very large numbers behind it. I've looked at this both pages: http://www.apache.org/dyn/closer.cgi http://httpd.apache.org/download.cgi When comparing it with the one from the current OOo project you should be able to see big differences: - too many links - too much data on one page - too much information to read to get an overview - too less clear structure So what do you want? A single download link that automatically selects the most appropriate mirror for the user? Yes. Everything else is not end-user compatible and needs to much effort to explain. That's easily done. I think you might be confusing the way that some projects choose to implement the download with how OO.o would be expected to implement the download. The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Marcus
RE: How to handle the downloads?
-Original Message- From: Andy Brown [mailto:a...@the-martin-byrd.net] Sent: Tuesday, 2 August 2011 8:48 AM To: ooo-dev@incubator.apache.org Subject: Re: How to handle the downloads? Marcus (OOo) wrote: Am 08/01/2011 09:25 PM, schrieb Ross Gardler: On 1 August 2011 18:20, Marcus (OOo)marcus.m...@wtnet.de wrote: AFAIK the current projects at Apache doesn't have high download numbers compared with OOo. So, a download request can point directly to a mirror or a mirror list is shown and the users have to choose themselves from where to get the software best. I wouldn't make any assumptions about the current mirror infrastructure. What you write above does not reflect how things work here. The ASF is a pretty large collection of projects with some very large numbers behind it. I've looked at this both pages: http://www.apache.org/dyn/closer.cgi http://httpd.apache.org/download.cgi When comparing it with the one from the current OOo project you should be able to see big differences: - too many links - too much data on one page - too much information to read to get an overview - too less clear structure Please keep in mind that we have to deal with end-users. Maybe there are a lot of power-users but even they prefer a simple and straight solution. ;-) I have to agree with Marcus on this. It has to be simple. Example, see this page: http://forrest.apache.org/mirrors.cgi Now , forget all the developer oriented content on that page and focus on the part that says: Current official release (closest mirror site selected automatically) Now, it has chosen the closest mirror already, the link to the file is there, they click on it and download it - what is the difficulty here, please explain? Perhaps the download link needs to be a big shiny blue/green graphic Icon with the words 'Download now!' on it to make more user intuitive, no problem there, you can do that. On the page is an 'Other' mirrors section where one can optionally choose another mirror if the chosen one is having issues for some reason (it should not, as all mirrors are checked hourly for their usefulness and removed from being a automatically chosen mirror if there are issues.) (this too is optional) So, effectively, you can remove everything and replace it with a pretty Download Icon, can't get any simpler than that. In other words, it can work in exactly the same way the current OpenOffice.org program downloads now. Oh, actually just checked, the nice and easy 'Download now!' button on openoffice.org redirects to http://planetmirror.com/pub/openoffice/ (for me) oops, now what is a user to do? My program didn't download, where is it, what's the filename I'm looking for, what does stable mean, hmm, ooh theres the word developer, perhaps Im in the wrong place, HELP! Gav... Andy
Re: How to handle the downloads?
Am 08/02/2011 12:49 AM, schrieb Rob Weir: On Mon, Aug 1, 2011 at 6:42 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/02/2011 12:15 AM, schrieb Ross Gardler: On 1 August 2011 22:51, Marcus (OOo)marcus.m...@wtnet.dewrote: Am 08/01/2011 09:25 PM, schrieb Ross Gardler: On 1 August 2011 18:20, Marcus (OOo)marcus.m...@wtnet.de wrote: AFAIK the current projects at Apache doesn't have high download numbers compared with OOo. So, a download request can point directly to a mirror or a mirror list is shown and the users have to choose themselves from where to get the software best. I wouldn't make any assumptions about the current mirror infrastructure. What you write above does not reflect how things work here. The ASF is a pretty large collection of projects with some very large numbers behind it. I've looked at this both pages: http://www.apache.org/dyn/closer.cgi http://httpd.apache.org/download.cgi When comparing it with the one from the current OOo project you should be able to see big differences: - too many links - too much data on one page - too much information to read to get an overview - too less clear structure So what do you want? A single download link that automatically selects the most appropriate mirror for the user? Yes. Everything else is not end-user compatible and needs to much effort to explain. That's easily done. I think you might be confusing the way that some projects choose to implement the download with how OO.o would be expected to implement the download. The ASF does not care what your download page looks like as long as you use the CGI scripts to ensure that an appropriate mirror site is used. Hm, let's see how independent the download thing really will be. ;-) Well, I think it is obvious that it is better to have a a single mirror system with the ability to customize the UI for each project than to have each project seek out a different mirroring network. Of course, I don't want to force the OOo mirror system now into the Apache project. It's how to make the best use of it. In other words, let's try to solve this with a JavaScript hammer if we can, and save the VM hammer for if we really need it. AFAIK we have tried it with JS but have decided to use Bouncer (from OSUOSL) and due to problems migrated then to MirrorBrain. MirrorBrain isn't and doesn't need a VM hammer. Currently it's running on a SuSE system with 512 MB RAM. Marcus
