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 <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.
----------------------------------------------------------------------------
--
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
