Re: [AOLSERVER] Windows Support
Well, I already made my point about Windows support. I believe it would be a mistake to remove it. On top of that I believe that full stack of components AOLserver + TCL and OpenACS have to work well together and should be able to do that on the most recent OSes and Databases. A delay in one of the components of the stack would have effects on all the others. I would favour efforts in these direction more than others even if more valid and interesting from a theoretical/experimental point of view. I believe the digression was useful to see things from this "components stack" point of view. Here I end, Maurizio -Original Message- From: Gustaf Neumann [mailto:neum...@wu.ac.at] Sent: 29 September 2012 14:31 To: aolserver-talk@lists.sourceforge.net Subject: Re: [AOLSERVER] Windows Support Maurizio, the mentioned thread in the OpenACS forum is about speed, not functionality. The issue came up for large sites when postgres changed the rules for their optimizer. I would think that most OpenACS sites work fine with current pg versions. The 9.* support is in OpenACS CVS since July last year (rather large change, bring stored procedures to the level of current postgres, substantial changes in 55 files, see [1]). Since recursive queries are as well rather new in pg, and the changes for OpenACS to use recursive queries requires update-scripts that might run a few hours, we sent the recursive query optimizations to the main stakeholders at the begin of this year and received little feedback so far (maybe they prefer to be conservative for their large sites, maybe they don't have the mentioned performance issue). The recursive query optimizations are as well publically available [2]. Yes, the code will go from our point of view into future OpenACS, but we are not the only OpenACS users, and we do not want to break other installations... This discussion is here somewhat off-topic, it has nothing to do with aolserver (or Windows support). -gustaf neumann [1] http://cvs.openacs.org/changelog/OpenACS/openacs-4/packages/acs-kernel [2] http://www.openacs.org/forums/message-view?message_id=3959984 On 29.09.12 13:15, Maurizio Martignano wrote: > Dear Gustav, > You wrote this post on the OpenACS forum: > http://www.openacs.org/forums/message-view?message_id=3847401 > > You are in the best position to explain this point, you decided to use > recursive queries (CTEs) and replace this way huge materialized tree tables. > I can only agree with this approach. > But what is this? Something you did in your installations, or > something commonly available in the OpenACS distributions, tar balls? > Has the OpenACS data model changed accordingly? > If yes my concern was a non-issue and I apologize for it. > If not my concern is real and OpenACS does not support the latest > versions of PostgreSQL. > > I hope to have been clearer this time. > > Maurizio > > -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
Re: [AOLSERVER] Windows Support
Maurizio, the mentioned thread in the OpenACS forum is about speed, not functionality. The issue came up for large sites when postgres changed the rules for their optimizer. I would think that most OpenACS sites work fine with current pg versions. The 9.* support is in OpenACS CVS since July last year (rather large change, bring stored procedures to the level of current postgres, substantial changes in 55 files, see [1]). Since recursive queries are as well rather new in pg, and the changes for OpenACS to use recursive queries requires update-scripts that might run a few hours, we sent the recursive query optimizations to the main stakeholders at the begin of this year and received little feedback so far (maybe they prefer to be conservative for their large sites, maybe they don't have the mentioned performance issue). The recursive query optimizations are as well publically available [2]. Yes, the code will go from our point of view into future OpenACS, but we are not the only OpenACS users, and we do not want to break other installations... This discussion is here somewhat off-topic, it has nothing to do with aolserver (or Windows support). -gustaf neumann [1] http://cvs.openacs.org/changelog/OpenACS/openacs-4/packages/acs-kernel [2] http://www.openacs.org/forums/message-view?message_id=3959984 On 29.09.12 13:15, Maurizio Martignano wrote: > Dear Gustav, > You wrote this post on the OpenACS forum: > http://www.openacs.org/forums/message-view?message_id=3847401 > > You are in the best position to explain this point, you decided to use > recursive queries (CTEs) and replace this way huge materialized tree tables. > I can only agree with this approach. > But what is this? Something you did in your installations, or something > commonly available in the OpenACS distributions, tar balls? Has the OpenACS > data model changed accordingly? > If yes my concern was a non-issue and I apologize for it. > If not my concern is real and OpenACS does not support the latest versions > of PostgreSQL. > > I hope to have been clearer this time. > > Maurizio > > -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
Re: [AOLSERVER] Windows Support
Jeff, i fully agree with you that this would be the right direction and a win-win situation for both communities. This would be however not only a question of "turning the build setup", but a substantial amount of rewriting of e.g. the i/o and threading layers. A few years ago i have looked a little into replacing aolserver's threading layer by libthread. That would give the benefit to have all threads sitting in an event loop, making thread reloading etc. much easier (connection and scheduled threads). I've failed to convince Zoran to move this way (due to the required amount of work). -gustaf neumann On 29.09.12 02:52, Jeff Hobbs wrote: > It is likely quite possible to turn things around and have AOLServer be > a set of extensions that load into a standard tclsh. The state of > extensions is pretty open, and again if more of the Tcl standard code > can be leveraged (socket handling, threading, etc.), this would be a > good thing. After all, a lot of that was originally influenced by > AOLServer code. > > I think this would be a win for portability as well as ease of use, but > it may be a larger task to turn the build setup on it's head than anyone > wants to undertake for a minor version update. > > Jeff > -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
Re: [AOLSERVER] Windows Support
Dear Gustav, You wrote this post on the OpenACS forum: http://www.openacs.org/forums/message-view?message_id=3847401 You are in the best position to explain this point, you decided to use recursive queries (CTEs) and replace this way huge materialized tree tables. I can only agree with this approach. But what is this? Something you did in your installations, or something commonly available in the OpenACS distributions, tar balls? Has the OpenACS data model changed accordingly? If yes my concern was a non-issue and I apologize for it. If not my concern is real and OpenACS does not support the latest versions of PostgreSQL. I hope to have been clearer this time. Maurizio == -Original Message- From: Gustaf Neumann [mailto:neum...@wu.ac.at] Sent: 29 September 2012 12:54 To: aolserver-talk@lists.sourceforge.net Subject: Re: [AOLSERVER] Windows Support Maurizio, i can't follow your concerns. We are running our production server currently with OpenACS and PostgreSQL 9.1.4; the limiting factor for database development is rather Oracle, since the community decided to support both platforms. The discussion has similarities to the aolser+window considerations). -gustaf neumann On 29.09.12 08:58, Maurizio Martignano wrote: > If OpenACS doesn't convert its data model, replacing hierarchical > structure with CTEs it will not run in an efficient way on PostgreSQL, > and that will be the death of OpenACS, and therefore of AOLserver (?) . > > ... > To be honest, from my limited point of view, I am not really worried > about AOLserver, it does work; what worries me is OpenACS having > problems with the new versions of PostgreSQL. > > All the best, > Maurizio > > > -Original Message- > > > From: Jeff Hobbs [mailto:je...@activestate.com] > Sent: 29 September 2012 02:53 > To: aolserver-talk@lists.sourceforge.net > Subject: Re: [AOLSERVER] Windows Support > > It is likely quite possible to turn things around and have AOLServer > be a set of extensions that load into a standard tclsh. The state of > extensions is pretty open, and again if more of the Tcl standard code > can be leveraged (socket handling, threading, etc.), this would be a > good thing. After all, a lot of that was originally influenced by AOLServer code. > > I think this would be a win for portability as well as ease of use, > but it may be a larger task to turn the build setup on it's head than > anyone wants to undertake for a minor version update. > > Jeff > > On 27/09/2012 4:11 PM, jgdavid...@mac.com wrote: >> How about making AolServer nothing more than a TEA-compliant extension? > Maybe we could create an "ns_main" command that created a thread that > did all the AolServer stuff (i.e., listen on sockets, create > connection pools, etc. etc.) and just run it in tclsh. >> I never looked at TEA close enough to know if that's a ridiculous idea... >> >> -Jim >> >> >> On Sep 27, 2012, at 11:25 AM, Jeff Hobbs wrote: >> >>> On 2012-09-27, at 1:56 AM, Maurizio Martignano > wrote: >>>> So what are the feasible options? >>>> I believe there are only two (well three) options: >>>> 1. we maintain the Windows code inside Aolserver (I favour this) 2. >>>> we compile Unix only code via the SUA SDK 3. we forget about >>>> Windows and we use real emulation, that is a VM running Linux >>>> >>>> But how many people are willing to download a VM of 1.5 GB or so >>>> just to test a system? >>> You might be surprised to hear that #3 and large downloads don't >>> faze a > lot of people if it means they get something that works. ActiveState > moved to this model with Stackato (a cloud platform - basically > Heroku-in-a-box), and we haven't heard concerns about download > size[1]. It's a custom linux vm that people can use from any OS (and > we have plenty that use it on or from Windows). >>> However, that's just a point that such things exist and are >>> accepted. I > for one would vote to keep the Windows support in AOLserver. I don't > think it's that hard anymore (having done dev on so many platforms > over the years), especially if you leverage the Tcl code base to the fullest extent. >>> What I would recommend is only sticking with an msys-based build >>> system (this means 'configure; make' on Windows). If someone really >>> wants to maintain an MSVC makefile that's fine, but I wouldn't >>> agonize over it. If you look at the latest TEA config files, they >>> enable this cross-platform build portabili
Re: [AOLSERVER] Windows Support
Maurizio, i can't follow your concerns. We are running our production server currently with OpenACS and PostgreSQL 9.1.4; the limiting factor for database development is rather Oracle, since the community decided to support both platforms. The discussion has similarities to the aolser+window considerations). -gustaf neumann On 29.09.12 08:58, Maurizio Martignano wrote: > If OpenACS doesn't convert its data model, replacing hierarchical structure > with CTEs it will not run in an efficient way on PostgreSQL, and that will > be the death of OpenACS, and therefore of AOLserver (?) . > > ... > To be honest, from my limited point of view, I am not really worried about > AOLserver, it does work; what worries me is OpenACS having problems with the > new versions of PostgreSQL. > > All the best, > Maurizio > > > -Original Message- > > > From: Jeff Hobbs [mailto:je...@activestate.com] > Sent: 29 September 2012 02:53 > To: aolserver-talk@lists.sourceforge.net > Subject: Re: [AOLSERVER] Windows Support > > It is likely quite possible to turn things around and have AOLServer be a > set of extensions that load into a standard tclsh. The state of extensions > is pretty open, and again if more of the Tcl standard code can be leveraged > (socket handling, threading, etc.), this would be a good thing. After all, > a lot of that was originally influenced by AOLServer code. > > I think this would be a win for portability as well as ease of use, but it > may be a larger task to turn the build setup on it's head than anyone wants > to undertake for a minor version update. > > Jeff > > On 27/09/2012 4:11 PM, jgdavid...@mac.com wrote: >> How about making AolServer nothing more than a TEA-compliant extension? > Maybe we could create an "ns_main" command that created a thread that did > all the AolServer stuff (i.e., listen on sockets, create connection pools, > etc. etc.) and just run it in tclsh. >> I never looked at TEA close enough to know if that's a ridiculous idea... >> >> -Jim >> >> >> On Sep 27, 2012, at 11:25 AM, Jeff Hobbs wrote: >> >>> On 2012-09-27, at 1:56 AM, Maurizio Martignano > wrote: >>>> So what are the feasible options? >>>> I believe there are only two (well three) options: >>>> 1. we maintain the Windows code inside Aolserver (I favour this) 2. >>>> we compile Unix only code via the SUA SDK 3. we forget about Windows >>>> and we use real emulation, that is a VM running Linux >>>> >>>> But how many people are willing to download a VM of 1.5 GB or so >>>> just to test a system? >>> You might be surprised to hear that #3 and large downloads don't faze a > lot of people if it means they get something that works. ActiveState moved > to this model with Stackato (a cloud platform - basically Heroku-in-a-box), > and we haven't heard concerns about download size[1]. It's a custom linux vm > that people can use from any OS (and we have plenty that use it on or from > Windows). >>> However, that's just a point that such things exist and are accepted. I > for one would vote to keep the Windows support in AOLserver. I don't think > it's that hard anymore (having done dev on so many platforms over the > years), especially if you leverage the Tcl code base to the fullest extent. >>> What I would recommend is only sticking with an msys-based build >>> system (this means 'configure; make' on Windows). If someone really >>> wants to maintain an MSVC makefile that's fine, but I wouldn't >>> agonize over it. If you look at the latest TEA config files, they >>> enable this cross-platform build portability pretty well. You can >>> still build with MSVC (or mingw-gcc), but you use GNU tools via msys. >>> How people operate on Windows without msys or similar tools is a >>> mystery to me. ;) >>> >>> Jeff >>> >>> [1] while we agonized about cracking through 1G download sizes early on, > the other day I saw a kid not think twice about downloading 1.4G on his Xbox > just to get a _demo_ of a game. The days of download limits are mostly > gone. > > > -- > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > ___ > aolserver-talk mailing list > aolse
Re: [AOLSERVER] Windows Support
Dear all, Please take what I say with a pinch of salt... I think we need some kind of reality checks: 1. AOLserver Though changes like the one mentioned here are very interesting from a theoretical point of view, they would require a lot of energy to be implemented. By the time AOLServer gets converted to a set of TCL extensions and properly supports OpenACS, all OpenACS community would move to Naviserver, and that would be the death of Aolserver. 2. OpenACS If OpenACS doesn't convert its data model, replacing hierarchical structure with CTEs it will not run in an efficient way on PostgreSQL, and that will be the death of OpenACS, and therefore of AOLserver (?) . 3. Windows If we look at a typical AOLserver/OpenACS applications, there are two types of binaries: 1. The core, that is Aolserver and its libraries, modules 2. Ancillary programs (little utilities called every now and then). Now while the second ones could be compiled with something like MinGW (the 64 bit version nowadays), the first ones, would be better if compiled with Microsoft tool chain, technically cause the generated binaries would have the standard format and layout expected by Microsoft, so they would be first class application, and also from a marketing point of view (especially for people responsible of IT departments), because in that case AOLserver would appear as belonging to the standard Microsoft ecosystem. To be honest, from my limited point of view, I am not really worried about AOLserver, it does work; what worries me is OpenACS having problems with the new versions of PostgreSQL. All the best, Maurizio -Original Message- From: Jeff Hobbs [mailto:je...@activestate.com] Sent: 29 September 2012 02:53 To: aolserver-talk@lists.sourceforge.net Subject: Re: [AOLSERVER] Windows Support It is likely quite possible to turn things around and have AOLServer be a set of extensions that load into a standard tclsh. The state of extensions is pretty open, and again if more of the Tcl standard code can be leveraged (socket handling, threading, etc.), this would be a good thing. After all, a lot of that was originally influenced by AOLServer code. I think this would be a win for portability as well as ease of use, but it may be a larger task to turn the build setup on it's head than anyone wants to undertake for a minor version update. Jeff On 27/09/2012 4:11 PM, jgdavid...@mac.com wrote: > How about making AolServer nothing more than a TEA-compliant extension? Maybe we could create an "ns_main" command that created a thread that did all the AolServer stuff (i.e., listen on sockets, create connection pools, etc. etc.) and just run it in tclsh. > > I never looked at TEA close enough to know if that's a ridiculous idea... > > -Jim > > > On Sep 27, 2012, at 11:25 AM, Jeff Hobbs wrote: > >> On 2012-09-27, at 1:56 AM, Maurizio Martignano wrote: >>> So what are the feasible options? >>> I believe there are only two (well three) options: >>> 1. we maintain the Windows code inside Aolserver (I favour this) 2. >>> we compile Unix only code via the SUA SDK 3. we forget about Windows >>> and we use real emulation, that is a VM running Linux >>> >>> But how many people are willing to download a VM of 1.5 GB or so >>> just to test a system? >> >> You might be surprised to hear that #3 and large downloads don't faze a lot of people if it means they get something that works. ActiveState moved to this model with Stackato (a cloud platform - basically Heroku-in-a-box), and we haven't heard concerns about download size[1]. It's a custom linux vm that people can use from any OS (and we have plenty that use it on or from Windows). >> >> However, that's just a point that such things exist and are accepted. I for one would vote to keep the Windows support in AOLserver. I don't think it's that hard anymore (having done dev on so many platforms over the years), especially if you leverage the Tcl code base to the fullest extent. >> >> What I would recommend is only sticking with an msys-based build >> system (this means 'configure; make' on Windows). If someone really >> wants to maintain an MSVC makefile that's fine, but I wouldn't >> agonize over it. If you look at the latest TEA config files, they >> enable this cross-platform build portability pretty well. You can >> still build with MSVC (or mingw-gcc), but you use GNU tools via msys. >> How people operate on Windows without msys or similar tools is a >> mystery to me. ;) >> >> Jeff >> >> [1] while we agonized about cracking through 1G download sizes early on, the other day I saw a kid not think twice about downloading 1.4G on his Xbox just to get a _demo_ of a g
Re: [AOLSERVER] Windows Support
It is likely quite possible to turn things around and have AOLServer be a set of extensions that load into a standard tclsh. The state of extensions is pretty open, and again if more of the Tcl standard code can be leveraged (socket handling, threading, etc.), this would be a good thing. After all, a lot of that was originally influenced by AOLServer code. I think this would be a win for portability as well as ease of use, but it may be a larger task to turn the build setup on it's head than anyone wants to undertake for a minor version update. Jeff On 27/09/2012 4:11 PM, jgdavid...@mac.com wrote: > How about making AolServer nothing more than a TEA-compliant extension? > Maybe we could create an "ns_main" command that created a thread that did all > the AolServer stuff (i.e., listen on sockets, create connection pools, etc. > etc.) and just run it in tclsh. > > I never looked at TEA close enough to know if that's a ridiculous idea... > > -Jim > > > On Sep 27, 2012, at 11:25 AM, Jeff Hobbs wrote: > >> On 2012-09-27, at 1:56 AM, Maurizio Martignano >> wrote: >>> So what are the feasible options? >>> I believe there are only two (well three) options: >>> 1. we maintain the Windows code inside Aolserver (I favour this) >>> 2. we compile Unix only code via the SUA SDK >>> 3. we forget about Windows and we use real emulation, that is a VM running >>> Linux >>> >>> But how many people are willing to download a VM of 1.5 GB or so just to >>> test a system? >> >> You might be surprised to hear that #3 and large downloads don't faze a lot >> of people if it means they get something that works. ActiveState moved to >> this model with Stackato (a cloud platform - basically Heroku-in-a-box), and >> we haven't heard concerns about download size[1]. It's a custom linux vm >> that people can use from any OS (and we have plenty that use it on or from >> Windows). >> >> However, that's just a point that such things exist and are accepted. I for >> one would vote to keep the Windows support in AOLserver. I don't think it's >> that hard anymore (having done dev on so many platforms over the years), >> especially if you leverage the Tcl code base to the fullest extent. >> >> What I would recommend is only sticking with an msys-based build system >> (this means 'configure; make' on Windows). If someone really wants to >> maintain an MSVC makefile that's fine, but I wouldn't agonize over it. If >> you look at the latest TEA config files, they enable this cross-platform >> build portability pretty well. You can still build with MSVC (or >> mingw-gcc), but you use GNU tools via msys. How people operate on Windows >> without msys or similar tools is a mystery to me. ;) >> >> Jeff >> >> [1] while we agonized about cracking through 1G download sizes early on, the >> other day I saw a kid not think twice about downloading 1.4G on his Xbox >> just to get a _demo_ of a game. The days of download limits are mostly gone. -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
Re: [AOLSERVER] Windows Support
How about making AolServer nothing more than a TEA-compliant extension? Maybe we could create an "ns_main" command that created a thread that did all the AolServer stuff (i.e., listen on sockets, create connection pools, etc. etc.) and just run it in tclsh. I never looked at TEA close enough to know if that's a ridiculous idea... -Jim On Sep 27, 2012, at 11:25 AM, Jeff Hobbs wrote: > On 2012-09-27, at 1:56 AM, Maurizio Martignano > wrote: >> So what are the feasible options? >> I believe there are only two (well three) options: >> 1. we maintain the Windows code inside Aolserver (I favour this) >> 2. we compile Unix only code via the SUA SDK >> 3. we forget about Windows and we use real emulation, that is a VM running >> Linux >> >> But how many people are willing to download a VM of 1.5 GB or so just to >> test a system? > > You might be surprised to hear that #3 and large downloads don't faze a lot > of people if it means they get something that works. ActiveState moved to > this model with Stackato (a cloud platform - basically Heroku-in-a-box), and > we haven't heard concerns about download size[1]. It's a custom linux vm that > people can use from any OS (and we have plenty that use it on or from > Windows). > > However, that's just a point that such things exist and are accepted. I for > one would vote to keep the Windows support in AOLserver. I don't think it's > that hard anymore (having done dev on so many platforms over the years), > especially if you leverage the Tcl code base to the fullest extent. > > What I would recommend is only sticking with an msys-based build system (this > means 'configure; make' on Windows). If someone really wants to maintain an > MSVC makefile that's fine, but I wouldn't agonize over it. If you look at > the latest TEA config files, they enable this cross-platform build > portability pretty well. You can still build with MSVC (or mingw-gcc), but > you use GNU tools via msys. How people operate on Windows without msys or > similar tools is a mystery to me. ;) > > Jeff > > [1] while we agonized about cracking through 1G download sizes early on, the > other day I saw a kid not think twice about downloading 1.4G on his Xbox just > to get a _demo_ of a game. The days of download limits are mostly gone. > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > ___ > aolserver-talk mailing list > aolserver-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/aolserver-talk -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
Re: [AOLSERVER] Windows Support
Maurizio Martignano wrote: > Dear all, > I do not think that removing Windows specific code is a good idea. Hi Maurizio, You make a good argument for keeping windows support. There is a cost of some added complexity, but I don't think that's unreasonable. The biggest challenges are keeping any platform-specific code up to date, testing builds, and perhaps producing binary distributions. I am personally in no position to support windows development, but if you or someone else is willing to commit to doing so, that would go a long way towards keeping the windows support in place. -J -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
Re: [AOLSERVER] Windows Support
On 2012-09-27, at 1:56 AM, Maurizio Martignano wrote: > So what are the feasible options? > I believe there are only two (well three) options: > 1. we maintain the Windows code inside Aolserver (I favour this) > 2. we compile Unix only code via the SUA SDK > 3. we forget about Windows and we use real emulation, that is a VM running > Linux > > But how many people are willing to download a VM of 1.5 GB or so just to > test a system? You might be surprised to hear that #3 and large downloads don't faze a lot of people if it means they get something that works. ActiveState moved to this model with Stackato (a cloud platform - basically Heroku-in-a-box), and we haven't heard concerns about download size[1]. It's a custom linux vm that people can use from any OS (and we have plenty that use it on or from Windows). However, that's just a point that such things exist and are accepted. I for one would vote to keep the Windows support in AOLserver. I don't think it's that hard anymore (having done dev on so many platforms over the years), especially if you leverage the Tcl code base to the fullest extent. What I would recommend is only sticking with an msys-based build system (this means 'configure; make' on Windows). If someone really wants to maintain an MSVC makefile that's fine, but I wouldn't agonize over it. If you look at the latest TEA config files, they enable this cross-platform build portability pretty well. You can still build with MSVC (or mingw-gcc), but you use GNU tools via msys. How people operate on Windows without msys or similar tools is a mystery to me. ;) Jeff [1] while we agonized about cracking through 1G download sizes early on, the other day I saw a kid not think twice about downloading 1.4G on his Xbox just to get a _demo_ of a game. The days of download limits are mostly gone. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
