[AOLSERVER] Is there anyone out there?

29 views
Skip to first unread message

Ayan George

unread,
May 10, 2014, 9:38:59 PM5/10/14
to aolserv...@lists.sourceforge.net

aolserver-talk has been quiet for a while. Has the discussion moved
somewhere else?

-ayan

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
aolserver-talk mailing list
aolserv...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

Dossy Shiobara

unread,
May 11, 2014, 10:50:13 AM5/11/14
to aolserv...@lists.sourceforge.net
On 5/10/14 9:38 PM, Ayan George wrote:
> aolserver-talk has been quiet for a while. Has the discussion moved
> somewhere else?
Not that I'm aware of ... but, it's possible there's some
NaviServer-focused list that has much more activity than this one.

--
Dossy Shiobara | "He realized the fastest way to change
do...@panoptic.com | is to laugh at your own folly -- then you
http://panoptic.com/ | can let go and quickly move on." (p. 70)
* WordPress * jQuery * MySQL * Security * Business Continuity *

Ayan George

unread,
May 11, 2014, 1:35:38 PM5/11/14
to aolserv...@lists.sourceforge.net
On 05/11/2014 10:50 AM, Dossy Shiobara wrote:
> On 5/10/14 9:38 PM, Ayan George wrote:
>> aolserver-talk has been quiet for a while. Has the discussion
>> moved somewhere else?
> Not that I'm aware of ... but, it's possible there's some
> NaviServer-focused list that has much more activity than this one.
>

First, sorry for the rambly email.

I remember a really encouraging thread titled "Roadmap - 4.6 and beyond"
but nothing seemed to come of it.

Perhaps now that usage is fairly low it is time to start making bold
changes to improve and modernize the code AND to attract new developers
and users.

I don't think inertia or alienating users would be a valid argument
against changes at this point.

This is a good time to set some hard goals, delegate tasks, etc. This
time, however, maybe Dossy can suss out what seems worthwhile and make
it happen?

Personally, I would like to see the following:

* Define the scope and goals of AOLserver. Personally, I'd like
AOLserver to be a high performance, programmable, TCL based web server
for Unix-like operating systems.

* Identify subsystems and assign a maintainer to each. Initially this
may be the same person or small group but the goal would be to delegate
ownership.

* Completely commit to a traditional git workflow. Accept patches on
the -talk submitted using list for review. Have subsystem maintainers
apply patches. Dossy then pulls from each maintainer's tree to cut a
release.

* Drop Windows support unless it is exceedingly easy to do. Right now
there are 86 #ifdef _WIN32 instances in the code -- IMHO, there should
be 0. Why worry about alienating an incredibly small (maybe
non-existent) sliver of an already tiny community?

* Allow, encourage, maybe insist upon more modern programming
techniques. There is a lot of classic C89 or pre-C89 code in AOLserver.
Many open source projects balk at using C99 features citing compiler
support and developer familiarity but C99 is about 15 years old now and
well supported. I think AOLserver would be a more attractive if we
explicitly required C99 features that can improve the quality of the
code (inline declarations, declarations in for() loops, restrict
pointers, etc.).

A simple goal like converting for() loops to c99 in-loop-declarations or
adding restrict keywords where useful would give developers an
opportunity to get familiar with the code without doing any heavy lifting.

* Modernize the main event loop. Perhaps use libevent for socket
multiplexing and thread dispatch. This will allow it to take advantage
of superior multiplexing techniques like kqueue() and epoll().

* SPDY, HTTP 1.1, HTTP 2.0?

* Support for deferred accepts (FreeBSD AcceptFilters, Linux
TCP_DEFER_ACCEPT).

* Ongoing code clean-up, feature addition, optimization, and bug fixes.

Bottom line though is that I'm not sure if we should be afraid to break
anything. I don't think anyone will notice. :^)

-ayan

Ayan George

unread,
May 11, 2014, 1:38:29 PM5/11/14
to aolserv...@lists.sourceforge.net
On 05/11/2014 01:35 PM, Ayan George wrote:

> * Completely commit to a traditional git workflow. Accept patches
> on the -talk submitted using list for review. Have subsystem
> maintainers apply patches. Dossy then pulls from each maintainer's
> tree to cut a release.
>

Eh -- this bullet point is mangled. I meant accept patches submitted
to -talk using git format-patch.

Maurizio Martignano

unread,
May 11, 2014, 5:15:25 PM5/11/14
to Ayan George, aolserv...@lists.sourceforge.net
Dear Ayan,
It is quite some time that the Aolserver and Naviserver communities
have joined their efforts and all new developments occur nowadays mostly on
Naviserver.

I believe you should extend your list of "desiderata" to this list:
https://lists.sourceforge.net/lists/listinfo/naviserver-devel.

As far for the future of Aolserver/Naviserver I see their evolution very
connected to the one of OpenACS.

I think that the union Aolserver/Naviserver - OpenACS historically was two
different things:
1. a feature reach platform for CMS and e-learning sites
2. an interesting and very productive/powerful platform to develop web
applications

But things have changed and keep changing:
1. social media are making legacy CMS and standard web sites less and less
important
2. web and mobile application are moving towards architectures with rich
clients (e.g. html5 based like SensaTouch, Oracle ADF, SAP SUP) and these
architectures are moving away from the legacy web application and
development model offered by Aolserver/Naviserver - OpenACS.

Hope it helps,
Maurizio

PS: About deleting Windows support in AOLserver I would like to rememeber
that perhaps the biggest user of Aolserver/OpenACS is still ]project-open[
and it might be interesting for you to look at these numbers:
http://sourceforge.net/projects/project-open/files/project-open/V4.0/

Jeff Rogers

unread,
Jun 24, 2014, 4:51:59 AM6/24/14
to Ayan George, aolserv...@lists.sourceforge.net
Ok, I've been sitting on this response for far too long now, I may as
well just send it out, perfection be damned.

That was probably my thread on "4.6 and beyond" you mentioned. Lots of
energy ... then life happened, and time vanished. I'd still love to
make things happen, I'm just short on energy right now.

I don't think the existing userbase has particularly held anyone back
from making changes, bold or otherwise. After all, people can always
not upgrade. (According to the reports, a significant portion of
aolserver users are still using version 4.0 or even 3). So if you want
to make changes - make them! The wonderful thing about source control
is that you get to keep your old stuff around.

About source control - this isn't the first time someone has suggested
using something else. Frankly, the strongest arguments for moving away
from CVS and to something else from from Chris Tsai at SF support. To
paraphrase, "cvs hosting is absolutely awful to support for a lot of
reasons, and needs regular maintenance windows. Pretty much anything
else is better." The SCM system in use is not going to attract
developers that would not have been otherwise interested, IMHO.

That's not to say a change would hurt, but my strongest inclination at
this point would be to move to svn or hg. (or fossil, but that seems to
be even less mainstream than cvs, plus SF doesn't support it).
If there's an overwhelming outcry of voices demanding a move, that
increases the motivation. "Overwhelming" here would mean 2 or 3 :)

Until then (or after) if you have any patches to submit, by all means
send then and I'll be happy to take a look, and most likely merge it in
- I've mellowed somewhat since the last time a patch was shared (sorry John)

All this said, NaviServer *IS* much more active these days, and lacks
the "smirk factor" that the name "AOLserver" carries. And a lot of the
goals you mention (in particular, code cleanup) are regularly undertaken
by Gustaf.

WRT Maurizio's comments:

> 1. social media are making legacy CMS and standard web sites less and less
> important
> 2. web and mobile application are moving towards architectures with rich
> clients (e.g. html5 based like SensaTouch, Oracle ADF, SAP SUP) and these
> architectures are moving away from the legacy web application and
> development model offered by Aolserver/Naviserver - OpenACS.

Legacy CMS and standard web sites are by no means going away. Even the
html5-iest site needs a server behind it, and even if most of the
display logic is on the client in the javascript framework of the week
if you want to be able to persist and share your updates the best way is
still to have a database backing it up.

What is getting less important is the ADP programming style of
interleaving logic and layout. acs-templating is a great approach to
this tho, and there will continue to be a need to take data from a
database and put it into some deliverable form.

Which raises a few questions with suggestions of projects around them.

The data format of choice these days seems to be json, with xml still
being a significant player. So, how is our support for those things?

XML - tdom works very well with aolserver, and is better than most xml
handling anywhere, regardless of programming language. (It doesn't do
XQuery, but I can live with that). My only gripe is that it's a
standard tcl package rather than an aolserver module, but that's a
difference hardly worth quibbling over.

JSON - not so much. At least, not that people have talked about. There
is a good json library available in yajl-tcl (aside from the array-list
mapping that plagues all the tcl-json libraries), which I have every
expectation would work well in aolserver, but I haven't tested. Plus it
could probably benefit from integration with the native database
operators, rather than only working with postgres handles. Anyone
interested in putting together the pieces here?

Speaking of databases, one of aolserver's biggest strengths has always
been its database connectivity. Granted, in the early days that was
because Oracle took 5 minutes and 5Mb for a connection so pooling was a
huge win when no one else was doing it, but it's still a good thing.
But that's about relational database, what about these fancy newfangled
no-ess-kyoo-ell databases that I've been hearing so much about (in
between yelling at kids to stay off my lawn)? Some of them have purely
REST apis (e.g., couchdb) while others have C apis that might benefit
from ns_db style pooling, or might just benefit from having a nice
interfact (mongodb, redis). They may or may not have a query language,
but the bdb driver shows a way with that.

Anyone interested in writing drivers for these?

(BTW: I *WILL* fix the sqlite driver soon - I promise! Although, since
no one has complained about it, I doubt anyone is actually using it,
which is a shame.)

There's other cool stuff that could be integrated too. There's lots of
interest in making CSS not suck so much, so there are things like LESS
and SASS. Having tight integration with either of those would be nice.
Or a similar flavor, based around a high-performance C-coded css
parser, perhaps. Any interest in taking this on?

Then there's programming languages. Don't get me wrong, I love tcl.
But there are other things out there, and more importantly, applications
written in other stuff out there. So why not take spidermonkey and
write a module for that so we could run javascript on the server? (hey,
why not run node.js on aolserver and be able to use multiple cores?)

SPDY and HTTP/1.1 are good goals too.

So ...

All of the above are (I think) interesting projects. But they don't
mean a thing unless someone is using them. OpenACS is great in that
regard: it is a more or less complete application. But there are other
things that can be done also, and I think it's restrictive to think of
aolserver as just the engine to power OpenACS.

I guess what this all comes down to is a few key questions:
1: what do you want to build?
2: what is needed to help you build that better/faster/stronger?
3: why aren't we doing it?

We need an answer to #1, get #3 out of the way, and then #2 is the way
forward.

-J
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
Reply all
Reply to author
Forward
0 new messages