Re: [AOLSERVER] Roadmap, Live Cycle & Windows Support
Hi, Yes -- I think I recall Naviserver splitting because we weren't responsive at Aol. Made sense at the time -- there was just no justification for Aol to support the project at the time. Merging back makes sense. I'm guessing it's easier to fix whatever is perceived as not working with Naviserver and freeze Aolserver than the other way around? Just a guess. I always liked the Naviserver name better anyway... -Jim >> One last comment: >> Is it really necessary to have separate AOLserver and >> NaviServer versions? The community is already small and now >> there are (partly?) redundant efforts. > > I think it started with a suggestion list something like what I posted, > but at the time AOL still employed most of the core developers and there > was internal pressure there (I'm guessing mostly for api stability) that > was at odds with the desires of the OSS community who wanted more > radical and incompatible changes to be considered. Since then AOL has > "downsized" that tech group and has no more interest in the project, so > such a split would probably not happen today. Could the two be > re-merged? Possibly. It's worth talking about. > > [Sincere apologies to anyone who was directly involved if I got the > details wrong] > > -J > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > aolserver-talk mailing list > aolserver-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/aolserver-talk -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
Re: [AOLSERVER] Roadmap, Live Cycle & Windows Support
Frank Bergmann wrote: > Hi Jeff, > > > Perfect, thanks a lot, I pretty much agree with your view. > >> SPDY and WebSockets > > I may underestimate the importance of these protocols. I > believe I haven't every heard about a real-world application > using these protocols. I would be interested to hear the > opposite. SPDY should be completely invisible: if the browser and server support it then things will just get faster; theoretically it could improve page load times by 50%, but some people have suggested it could be much less than that. Still, faster is faster. WebSockets is an application tool, can do the same things as AJAX but with a lot less overhead. Expect to see more of it as it becomes more standardized and widely available. > Anyway, these are probably add-ons with little impact on > the stability of existing functionality, so that should be > "mostly harmless". Yep, that's the plan. >> shiny new feature > > The most shiny features that I see in AOLserver/NaviServer > are in the area of scalability and reliability. I'm a fan of flexibility, personally. But even though web/application servers are infrastructure, there still are things that come up that might not be especially new in what they're doing, but in how they are delivered. And having certain features in the infrastructure can greatly simplify deployment of these things. A case in point is google's mod_pagespeed for apache. It does a handful of transformations to the output of the web app, coalescing javascript files, changing css to be inline, etc. These things are not difficult to do to a single page, new application, or well-templated system, but can be quite time-consuming to do to thousands of webpages across unrelated systems. How well this all works may be debatable, but say "google likes it" and you instantly get the attention of certain people. This kind of post-application filtering was the motivation for Ns_ConnGetResponseContent and Ns_ConnSetResponseContent and the pre-write filter - it allows a way to look at and change the data being sent to the user after being generated and before being sent. Being able to do it in tcl makes it very easy to work with and flexible. And flexibility breeds interesting new uses; for example I realized that this could be used to implement full-page caching within the server with fine-grained control over expiry, without touching any other application code. It's almost like putting varnish in front of your server, but without another deployment headache. >> ]po[ > > We've thought a bit about what we (]po[) expect from a new > version of AOLserver. The truth is: not much (for the core > of ]po[). Just please continue with Win32 and fix the memory > bloat issue in 4.5.1 (or recommend an appropriate TCL version > or whatever). Can you give more info on the bloat problem? Or point to other threads, etc.. > One last comment: > Is it really necessary to have separate AOLserver and > NaviServer versions? The community is already small and now > there are (partly?) redundant efforts. I think it started with a suggestion list something like what I posted, but at the time AOL still employed most of the core developers and there was internal pressure there (I'm guessing mostly for api stability) that was at odds with the desires of the OSS community who wanted more radical and incompatible changes to be considered. Since then AOL has "downsized" that tech group and has no more interest in the project, so such a split would probably not happen today. Could the two be re-merged? Possibly. It's worth talking about. [Sincere apologies to anyone who was directly involved if I got the details wrong] -J -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
Re: [AOLSERVER] Roadmap, Live Cycle & Windows Support
Hi Jeff, Perfect, thanks a lot, I pretty much agree with your view. > SPDY and WebSockets I may underestimate the importance of these protocols. I believe I haven't every heard about a real-world application using these protocols. I would be interested to hear the opposite. Anyway, these are probably add-ons with little impact on the stability of existing functionality, so that should be "mostly harmless". > shiny new feature I'd consider Web servers as "infrastructure" to Web apps, in the same way as operating systems and hardware are infrastructure. Innovation has moved away from the infra- structure and towards other areas (business models, mobile, ...). I'd agree with you that IPV6 and drivers for new backends are just these measures to alliviate migration pressure. The most shiny features that I see in AOLserver/NaviServer are in the area of scalability and reliability. However, the scalability discussion in the media is completely dominated by "big data", non-SQL and similar stuff. So I guess we've got a PR problem here. Maybe Gustaf should write an article about his large-scale installations. > survey Maybe some of the OpenACS guys here in the list could setup a "simple-survey" on www.openacs.org. We could also set this up on www.project-open.org if you like. What are the fields? - Name, email and company (textfields, optional) - Number of installations (number) - Average size of users per installation (number) - Hardware platform (textfield) - Operating System (textfield) - AOLserver version (textfield) - OpenACS version (textfield) - Custom software (textarea) - What I most like about AOLserver (textarea) - What I most dislike about AOLserver (textarea) - Most wanted new features/improvements (textarea) > ]po[ We've thought a bit about what we (]po[) expect from a new version of AOLserver. The truth is: not much (for the core of ]po[). Just please continue with Win32 and fix the memory bloat issue in 4.5.1 (or recommend an appropriate TCL version or whatever). One last comment: Is it really necessary to have separate AOLserver and NaviServer versions? The community is already small and now there are (partly?) redundant efforts. Cheers! Frank -Original Message- From: Jeff Rogers [mailto:dv...@diphi.com] Sent: Tuesday, October 02, 2012 9:46 PM To: Frank Bergmann Cc: aolserver-talk@lists.sourceforge.net Subject: Re: [AOLSERVER] Roadmap, Live Cycle & Windows Support Frank Bergmann wrote: > Hi! > > > I believe that it is important to consider the current phase of the > "live cycle" of AOLserver in order to focus the roadmap on the > important stuff: > > - AOLserver is "mature" software, there were relatively >few changes in the last few years. There are very >large productive installations relying on AOLserver. I agree with this; we should be very careful to maintain compatibility and continue support of existing functionality. It seems there's a consensus that it's worthwhile to maintain windows support. > - AOLserver is close to the end of it's live cycle, >because there are few new installations. Instead, >many users and projects have already migrated away >towards Apache etc. > > - New features will probably convince few additional >people to use AOLserver. These I'm not so sure of. New features may or may not attract new people, but my larger concern is that without certain new features (e.g., support for new protocols like SPDY and WebSockets, and interfaces to popular infrastructure bits like memcache or NoSql databases) there will be increasing pressure to migrate away. > - Instead, and that would be my conclusion, new versions >of AOLserver should reduce the migration pressure for >existing users and allow the existing user to extend >the lifetime of their installations. This I agree with; but as above, a shiny new feature in apache/node.js/ngnix/etc that aolserver doesn't match creates migration pressure. > Would you agree with this assessment? Maybe we should have a survey > who is still using AOLserver really... I'd be very interested in seeing such a survey also. OpenACS and ]po[ are definitely the most visible users, but I think they are far from the only ones. -J -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
Re: [AOLSERVER] Roadmap, Live Cycle & Windows Support
Frank Bergmann wrote: > Hi! > > > I believe that it is important to consider the current > phase of the "live cycle" of AOLserver in order to focus > the roadmap on the important stuff: > > - AOLserver is "mature" software, there were relatively >few changes in the last few years. There are very >large productive installations relying on AOLserver. I agree with this; we should be very careful to maintain compatibility and continue support of existing functionality. It seems there's a consensus that it's worthwhile to maintain windows support. > - AOLserver is close to the end of it's live cycle, >because there are few new installations. Instead, >many users and projects have already migrated away >towards Apache etc. > > - New features will probably convince few additional >people to use AOLserver. These I'm not so sure of. New features may or may not attract new people, but my larger concern is that without certain new features (e.g., support for new protocols like SPDY and WebSockets, and interfaces to popular infrastructure bits like memcache or NoSql databases) there will be increasing pressure to migrate away. > - Instead, and that would be my conclusion, new versions >of AOLserver should reduce the migration pressure for >existing users and allow the existing user to extend >the lifetime of their installations. This I agree with; but as above, a shiny new feature in apache/node.js/ngnix/etc that aolserver doesn't match creates migration pressure. > Would you agree with this assessment? Maybe we should have > a survey who is still using AOLserver really... I'd be very interested in seeing such a survey also. OpenACS and ]po[ are definitely the most visible users, but I think they are far from the only ones. -J -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
Re: [AOLSERVER] Roadmap, Live Cycle & Windows Support
It appears there is enough consternation about removing Windows support that I doubt figuring out how to run AOLserver on Windows sans the Windows-specific code in the codebase would result in having the Windows code removed anyway, so I am rescinding my suggestion that we find a way to do so. /s. On Sep 27, 2012, at 7:36 AM, Frank Bergmann wrote: > Hi! > > > I believe that it is important to consider the current > phase of the "live cycle" of AOLserver in order to focus > the roadmap on the important stuff: > > - AOLserver is "mature" software, there were relatively > few changes in the last few years. There are very > large productive installations relying on AOLserver. > > - AOLserver is close to the end of it's live cycle, > because there are few new installations. Instead, > many users and projects have already migrated away > towards Apache etc. > > - New features will probably convince few additional > people to use AOLserver. > > - Instead, and that would be my conclusion, new versions > of AOLserver should reduce the migration pressure for > existing users and allow the existing user to extend > the lifetime of their installations. > > Would you agree with this assessment? Maybe we should have > a survey who is still using AOLserver really... > > > Concerning ]project-open[ (we had some 200.000 downloads on > SourceForge and there are some ~50 developers involved with > ]po[ in one form or another): > > - We have approx. 10x more ]project-open[ users running on > Windows then on Linux. I don't particularly like the Win > version, but removing this version will have a devasting > impact on ]po[. A VMware version is not a replacement for > a Windows installer. We are increasingly going for "stupid" > users, and these guys want a clean and easy installer for > their Win box. > > - I'm a personal fan of CygWin, and a CygWin version would > be OK for us even with 32bit. However, I believe there are > other users (Quest) who have customers asking for high- > performance Windows installations. Dropping a native > Win version might force Quest to migrate. > I can also imagine that the Windows platform will become > more important for our upcoming ]po[ V4.0 release because > we will target larger corporations who are typciallly > Windows shops in the US. > > - We are already hedging for an end of AOLserver live cycle: > www.openacs.org/forums/message-view?message_id=3637561 > It will be painful, but I believe it will come some day. > Please don't accellerate this moment unnecessarily... > > > Cheers! > Frank > > --- > Frank Bergmann > Dipl.-Ing., MBA > Founder ]project-open[ > Tel: +34 933 250 914 > Cell: +34 609 953 751 > Fax: +34 932 890 729 > mailto:frank.bergm...@project-open.com > http://www.project-open.com/ > > > -Original Message- > From: Maurizio Martignano [mailto:maurizio.martign...@spazioit.com] > Sent: Thursday, September 27, 2012 10:56 AM > To: aolserver-talk@lists.sourceforge.net > Subject: [AOLSERVER] Windows Support > > Dear all, > I do not think that removing Windows specific code is a good idea. > Some time ago I showed as example how many people have downloaded > ]project-open[ on Windows as opposed to the VM, or the tar ball. > In case you do not remember the numbers, please have a look at this URL: > http://sourceforge.net/projects/project-open/files/project-open/ > > The idea of using some kind of emulation is also questionable. Why? > Suppose we want to have Aolserver on Windows , then the emulation layer > would impose unacceptable inefficiencies. Here we are not talking about > using some emulation layer to run some ancillary programs, called every now > and then (e.g. dot, wget, and so on), but Aolserver itself (i.e. nsd), the > very heart of every OpenACS based web application. > The same type or reasoning applies to the database engine (e.g. postgresql), > it would be a major error running it on some emulation layer. > > What is the current status of these emulation layers? > > I know everybody is thinking about Cygwin... But Cygwin is, at the time > being only a Win32 application. > > Nowadays all the servers are 64 bit machines. Soon the same will be for > desktop and laptop computers. With Cygwin on 64 bit Windows machine we have > double emulation: > > Linux/Unix Application > - > Cygwin/ Posix emulation > - > WOW64/ Win32 emulation (this is Windows 32 emulated on Windows 64) > - > Windows 64 > > I can’t see any sign of Cygwin moving towards Windows 64. Last year in > summer there was an interesting discussion about that > (http://thread.gmane.org/gmane.os.cygwin.devel/233/focus=247) but nothing > happened because the effort is too big and nobody had enough energy to spend > on it. > > For how long will WOW64 be supported by Microsoft? It is already an option > in the core part of Windows Server 2008 R2
