[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 cant 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 (http://msdn.microsoft.com/en-us/library/dd371790%28v=vs.85%29.aspx). MingGW can now compile for Windows 64 but it lacks the Posix emulation available in Cygwin. Another (kind of emulation) solution would be compiling Aolserver with Visual Studio 2010 (or 2012) + SUA SDK (Utilities and SDK for Subsystem for UNIX-based Applications) (these two build both in 32 and 64). I am sure very few people know about this possibility. 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? A Windows installer of 150MB or so is much, much more attractive. Later on, if they are happy with the system, people can stick to Windows or use Linux for production. What do you think? Maurizio -Original Message- From: Wolfgang Winkler [mailto:wolfgang.wink...@digital-concepts.com] Sent: 27 September 2012 09:11 To: aolserver-talk@lists.sourceforge.net Subject: [AOLSERVER] TCL websockets Implementation Hi! I've cleaned up our websockets code a bit (ah, the joy of it), it should run now on a basic AOLserver install. Where should I post it? Wolfgang -- digital concepts OG Software Design Landstrasse 68 / 5. Stock A - 4020 Linz Büro: +43 732 99711772 Mobil: +43 699 19971172 -- 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] Roadmap - 4.6 and beyond
Has anyone analyzed Naviserver performance and features vs. AOLserver lately? It appears to remain compatible with Windows. The following forum post suggests Naviserver may be a contributing factor to a significant overall performance increase: http://openacs.org/forums/message-view?message_id=3957131 Maybe AOLserver 5 should start as a fork of Naviserver? ;-) On 09/27/2012 06:25 AM, Andrew Piskorski wrote: On Wed, Sep 26, 2012 at 09:07:07AM -0600, jgdavid...@mac.com wrote: Should we dump the Windows port in favor of a clean Unix code base, configure, build, and install? Cross-platform portability is very Nice to Have, and I've actually used it. Fortunately I've never had to deal with or even look at the Unix vs. Windows compatibility layer, so I can't speak on its maintenance burden. It just worked. That was really nice when (unexpectedly) porting my code from Solaris to Windows. The AOLserver Windows build process back then indeed seemed pretty bad; far too much unscriptable Microsoft project file crap. But I thought someone cleaned that up later. On Wed, Sep 26, 2012 at 09:24:41AM -0600, jgdavid...@mac.com wrote: For folks using Windows, I always follow up with the question: With VMware, Parallels, etc. today, even if you're bound to Windows hardware, can you just virtualize away the difference? Absolutely not. In my case, it's because I use AOLserver as a custom app server, which needs to build against proprietary libraries that are ONLY available on Windows. If what you need is a native Windows library, running Linux in a virtualized container is of no help whatsoever, you might as well be running on a remote Linux box. (Cygwin I'm not sure about. Can Cygwin applications build with native Windows libraries?) In my case, actually what happened is the proprietary vendor library discontinued Solaris support, leaving only Windows, so I ported to Windows. I'm still running it on Windows today. Now, if I was writing that same app today I might do things somewhat differently. But it was Really Nice that the custom AOLserver app I'd originally written on Solaris mostly Just Worked when I ported it to Windows. My own AOLserver on Windows use case is likely very atypical, but I think it's still a useful minor example of how cross-platform portability can be unexpectedly helpful, even when you originally didn't think you'd need or want it. Is cross-platform support in AOLserver worth the maintenance burden? Not having worked on that code, I can't say. But I can say that the cross-platform code does have real value, and was probably a lot of work to get right way back when, so I'd caution against throwing it out without a very clear case that doing so is worth more than the loss, and that there isn't some better way to achieve the same gains. My (completely unfounded in any hard evidence) gut-level suspicion is that 80% of the simplicity gains to be had from completely discarding Windows support are likely achievable by instead re-factoring (somehow or other) whatever parts are actually giving maintainers the most trouble. -- 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 maurizio.martign...@spazioit.com 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
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 je...@activestate.com wrote: On 2012-09-27, at 1:56 AM, Maurizio Martignano maurizio.martign...@spazioit.com 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] Suggestions for a future aolserver
John Buckman wrote: SUGGESTIONS FOR A FUTURE AOLSERVER The state of the art is, I think, happening in the javascript world, with things such as node.js. If the aolserver community were really interested in getting new users, making it a top notch embedded-javascript web server would be a way. I'm not sure this makes any strategic sense (nor that I need it), but there you go... I'm far from the first person to chuckle at how netscape introduced server-side javascript 15 years ago, it pretty much vanished for a while, and has now come roaring back as the next big thing. Plus ça change, plus c'est la même chose. Still, a ns_spidermonkey module would be a interesting project. The other area where state of the art thinking is occurring, is in scaling web sites to many, many machines. aolserver has some features to make that happen, but imagine if we had multi-machine ns_cache support, perhaps with a file system backup (ie, memcached)? I was thinking about this also. There is a nsmemcache module for naviserver, but it uses some of the C apis that have been changed slightly in naviserver, so it doesn't work with aolserver, but it shouldn't be difficult to port. A version (not sure if it's the most current) is at http://naviserver.cvs.sourceforge.net/naviserver/modules/nsmemcache/ Another bit of existing code to build a high-scalability cluster is the Digital City extensions that the guys at AOL built sometime before 2006 (I don't know exactly when, just estimating based on timestamps) and I believe ran some pretty big (for the day) sites on. It looks like a hidden treasure of functionality that never got the respect it deserved. Looking at the archives, there was some chatter about it on this list back in 2007. What's that french saying again? :) It currently lives at http://code.google.com/p/nsdci/ Also, support for sending an http page request to another machine (or pool of machines) would very handy, with a single http daemon handling them all with async io. I don't think this would be difficult as things are now; it would make a nice piece of example code. -J -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
