Forum OpenACS Development: Apache support critical
This evening I had a chat with the CTO of a /MAJOR/ online community - the kind that is both technically impressive and very sexy. He was attracted to OpenACS because of our internationalization support, but could not even consider OpenACS because of his current commitment to Apache.
I know the benefits of AOLserver well and I'm as good as anyone at selling AOLserver as a technology. I've done it before in pretty extreme environments and certainly have plenty of faith in it and its community. There's no doubt that for large installs and for our development, it should be our preferred development environment.
However, I do think we need to ask whether we are a web development environment or a software stack. If we are the latter, then we obviously should stay with AOLserver.
If, however, we are the former, we cannot continue to rely exclusively on AOLserver as the only reasonable way to deploy OpenACS. Five or ten years ago AOLserver was clearly the leader in web/db applications and it still is today.
However, Apache (and IIS) have proven themselves very capable and have caught up in many of the areas that AOLserver is strong. There's no reason that we should be tying ourselves to AOLserver as both an http listener /and/ application server.
In today's current software climate, we have two oddball techs - Tcl and AOLserver. We can survive with one, but with two things just get too hard.
John Sequeira has laid down a path in Portable.nsd in which we can solve these problems very elegantly. I would like to strongly recommend to the community (and to those nondevelopers who have a great deal at stake in the adoption of OpenACS and .LRN) to consider pushing his work into a complete solution.
I completely agree. An Apache port would make a huge differencce in getting large/small organizations using the system and participating in the development.
There's also another question - will a simple in-Tcl solution like John's scale well? If it's slow as a dog in the Apache environment it will make us look worse, not better.
The best solution would clearly be to find funds to pay someone to make a mod_aolserver work for the Apache 2.0 architecture. You'll recall aD had that for Apache 1.0.
You may also recall that after all their handwringing about needing to have ACS run under Apache that in the end you could count the clients/users who did so on one hand.
My cynical side says your CTO would've found another reason not to consider OpenACS if you'd had it running under Apache.
without having to resort to using fingers.
I do agree it would be less of a hurdle to get people to adopt OpenACS if it ran in apache and it would vastly increase the availability of cheap hosting (I think it would at least), but yeah, unless it works well and someone funds the work I doubt it would happen.
Maybe it's something dotlrn could put out an rfp for and see where people would be willing to do it. I could guess at $'s for doing this but I am thinking its a 4-6 month project to get it to the point where you could run production sites with it. Otoh, I have not looked at it since aD days and it's certainly getting easier with the changes made to modularize aolserver.
Or something more technical like he has current applications written in, say, Apache mod_perl and he needs seemless and high-performance interoperability between those apps and OpenACS? (If that example is it, I don't see how simply replacing AOLserver with Apache for OpenACS use would solve any of his integration problems, actually. But I might be missing important details.)
It would be helpful to know the actual precise needs and use cases of folks like this CTO...
My pure tcl approach has proved challenging because of several API disconnects between nstcl and Aolserver, which I haven't been able to address in a reasonable amount of time. Once/if the issues I've hit are addressed, I think it would need less maintainence by less technical coders. On scalability, I don't believe scalability will be an issue, but Don's right to point out I have no first-hand evidence of this. As a data point, I'm currently deploying perl+fastcgi apps that I ported from mod_perl+linux to IIS at several multinationals. The app scales pretty well ... but, who knows? tcl/openacs may be a lot different without AOLServer's c routines.
So, although I still have hope for portable.nsd, I would like to put forward a possibly simpler option: have AOLServer support FastCGI directly. Then you can be assured that the openacs tcl code will run unmodified on any web server that supports cgi... the performance will be on par etc. FastCGI hasn't changed in like a decade ... so you just have one side of the API maintainance problem instead of two. And, fwiw, Zope implements IIS support this way.
Although I don't know for sure what this would entail, and it's not a one-off cost, I have to believe that tweaking AOLServer to respond to a request coming in from a socket is a smaller deal that meshing large, mostly incompatibly APIs like AolServer<->nstcl, AolServer<->ISAPI or AolServer<->Apache2.
Here's a discussion on extending AOLServer to support multiple protocols (a necessary pre-req, I suspect)
> you could count the clients/users who did so on one hand.
without having to resort to using fingers.
Not true at all. Saying that suggests that not being in the position of selling the OpenACS.
If Apache and IIS were supported many more people take a look at deploying hte OpenACS.
The scalability issue seems to be red herring. What kind of sites are running OpenACS that are having scalability problems that aren't in the application code? All scalability problems seem to be in the database layer, not at the web/app server level. That could be an indication that AOLserver solves a really hard problem very well, or it solves a particular problem that other servers solve just as well. Evidence suggests the latter
Furthermore, if we're talking just adoption, there are very few OpenACS/.lrn sites out there that need such massive scalability. Most OpenACS/.lrn sites will not have even 1K users and as such they won't need to worry about the kind of traffic AOLserver is ideally suited for.
Finally, Apache is used in a much flexible manner than AOLserver ever can. The modular interface with all of the different mods means that an infrastructure can be built such that Apache can interface java, php, perl etc applications. In addition, if someone builds a complex system with many redirects and virtual hosts using Apache's idiosyncratic solutions it will be a massive expensive to switch to another web app server entirely.
>> you could count the clients/users who did so on one hand.
> without having to resort to using fingers.
Not true at all. Saying that suggests that not being in the > position of selling the OpenACS.
Wait, are saying there was more than 1 client who
really used mod_aolserver? I don't know of any
and I doubt there was more than one -- if you know
who did use it I would be interested in hearing about it.
I don't dispute that if we could use apache it would open
some doors but given that mod_aolserver did get written and
it did not spark any real additional interest in ACS
as far as I could tell, why it would be different now?
I am not sure what you mean by Apache is used in a much flexiable manner? Apache is used and has more tools available for it, but Apache and AOLserver are to very different products there were developed with different approaches to doing this thing we call ``web server''.
Apache, itself, has not internal scripting language. By that design it HAD to be able to interface to outside languages, since that became the web markets driving force. AOLserver was built to use TCL. It never needed the ability to interface with other ``things''. One can build AOLserver modules (nsxml, nsjabber, nspam, etc.) in the same way that people build apache modules. Most people that use AOLserver don't see the NEED for them as they usually can be done ``in server''. You can't really compare the two. You use them for different purposes although the final goal is to display websites.
In terms of intergrating Apache and AOLserver in mixed enviorments, it is possible and very simple. It is not expensive or difficult to do. People mention how flexible Apache is and at the same time talk about how hard it is to us it with anything else.
If one is really wants to some merge apache and OpenACS it would be an easier task to use the xql files and databases as a base to build a php/java/python/etc application around it. In both cases (mod_aolserver or a complete different language) you'll be spending quite a bit of time keeping code in sync.
a) .LRN is a product that is to be sold as a system that can be slid into an organizations infrastructure rather than what aD was selling - consulting services built around their preferred stack
b) mod_aolserver was a piece of crap and never was a real alternative. I don't think even the authors considered it to be anything other than a gee whiz tool. /the interest in mod_aolserver, though, was very significant/
c) The web app environment has changed considerably in the 5 years or so since aD and mod_aolserver. Apache, Linux, IIS... web development in general is a different environment. whether that is good or not is debatable, but the fact that there isn't the same lack of familiarity with web/db applciations
i'm not suggesting that AOLserver be abandoned. it's still the preferred web app server. but to penetrate IT departments at major organizations (corporate or educational) more flexibility needs to be introduced at the web server level.
furthermore, i'm intimately familiar with the crap that Apache is. remember, we tried to yank out moddav from Apache2 and stick it in AOLserver which was a disaster because the apache code is so poor. it turned out using AOLserver, Tcl and tdom was not only far more productive but far more flexible to implement this system. the success of this approach is becuase of AOLserver's focused and simple architecture.
however, Apache has proven to allow a more heterogenous system environment. for many IT orgs serving many different purposes, this is very critical (as you all well know).
i think, also, if you speak with some of the .lrn folks you will hear that many of them have had similar experiences. certainly my experience here is not unique.
John' s suggestion of either building a fastcgi interface for AOLserver or continuing portable.nsd seem to be both very effective solutions to this problem.
Talli, everybody has known for years that being able to run OpenACS on Apache in addition to AOLserver should obviously be a Good Thing. There's nothing new there. You started off this thread though, by suggesting that you had hard, concrete details on how and why a "major CTO" thinks he would adopt OpenACS if only he could run it on Apache. That is new, and interesting, but I have yet to see any real info at all about that CTO's actual problems and how OpenACS on Apache would help solve them. Please fill us in...
What do people think it would cost to get there? I threw out 4-6 months, which if you had someone talented and cheap (i.e. rare) that would be about $30k. Of course, like I said,
I am really just guessing and I certainly would not take it
on that cheaply.
John, what do you think it would cost to get the fastcgi
option working? Who do you think could do the work?
If so, then sure, better OpenACS Apache support would still be a A Good Thing, both technically and especially to head off these sorts of business objections, but we didn't learn anything new or useful from this CTO.
If OACS is positioned in the "application server" space, it is competing against Java based app servers. These require (IMHO) far more work to install and manage. There are the java libraries to worry about, plus the C or C++-based libraries that the java libs use. Just like AOLserver, the JVM is a separate Unix process from Apache.
There is almost an exact correlation between the way you set up Apache plus your favorite Java app server and the way you set up Apache and OpenACS behind it. The difference is that OpenACS requires about 4 lines of Apache config and Java requires a lot more than 4 lines.
I wonder if you had just told him that the AOLserver part is the multithreaded library if he would have even noticed. In terms of performance, there is little difference between Apache with AOLserver/ OpenACS behind it, and just AOLserver with OpenACS.
"Since the JVM is multithreaded; the jni worker should be used only within multithreaded servers such as AOLServer.."
Of the two approaches,
I think the latter would take less time. Since pnsd's current issues have stumped me (debugging query parser, implementing list builder and ad_form in pure tcl), I can't take a guess at how much longer it would take. I think they're solvable, but for someone closer in tcl ability to Michael Cleverly.
For adding FastCGI support to AOLServer, there are a large number of fastcgi implementations, including several in C (see fastcgi.com) and one or two in TCL
Looking at the example code, I'm guess you're talking < 1K SLOC to implement this, most of which is already written. It is probably on par with implementing a new database module.
I don't think that's 3-6 months, but maybe if AOLServer is really hard to hack on. Which I doubt.
As Patrick points out, this approach puts AOLServer on par with how most Java Servlet engines run -- out of process and speaking through a socket to some in-process connector. However, from my own experience with fastcgi/apache, configuration will be much closer to mod_rewrite+mod_proxy than mucking with xml config files to make your java app server happy.
Crucially, going this route also gets you IIS support for free (where mod_proxy is not an option).
As to who can do it... I think anyone who could extend AOLServer would be qualified to do this.
That's the only thing standing in your way ...
Andrew, it's not just a technical issue. Introducing OpenACS into a heterogenous environment is a lot more complex if we don't have a clear answer to how to run OACS behind Apache, IIS or other webservers that have already been set as the canonical application front end.
John Sequeira can answer this question much better than I, though, and so I will ask him if he has a bit of time to fill out this perspective.
I think Talli and you are talking forests and trees here, and that this is more of a forest-type discussion. Isn't it reasonable to assume that of the 99.9% of the world that prefers a webserver other than AOLServer, a decent fraction of them will look for solutions that support that web server?
So, in the case of internationalization, why would someone bother learning more about OpenACS if there are other semi-comparable solutions that don't require an addition to their web infrastructure? I believe that in Talli's experience, OpenACS is very often excluded from the initial short-list selection stage for this reason. It doesn't get to the point where a possible user starts worrying about what type of glue infrastructure you'd need to deploy it (what you've focused on) because it fails the web server litmus test. We can argue about whether this is fair or not, but not whether or not it happens. A lot.
This shouldn't be hard to grasp. For example, it's not like the OpenACS community thinks even a second of using Apache+mod_webdav to expose the content repository instead of rolling their own (thanks to Talli). That was a good decision, and I think that catering to other people's desire to think the same way makes sense.
Jade, portable.nsd could be deployed as a starkit with tclhttpd. Assuming postgresql will always have decent installers (deb/rpm/MSI), you'd have to work very very hard to make installing the openacs part challenging.
I've corresponded with some of the people who wrote multi-protocol patches for AOLServer. They were uniformly not optimistic their work would make it into core, which might just rule out implementing FastCGI in AOLServer. That would mean portable.nsd is the only option. I'll post to the AOLServer list and confirm this.
The customer gets Apache and can configure it as he pleases.
For example, the installation I manage uses some fancy mod_rewrite stuff to closely mimic previous URL structures that lots of external links take for granted. We map three different application servers into the general URL hierarchy (in addition to AOLserver), and let Apache handle SSL under a common certificate (just needed to convince ECommerce NOT to require SSL). This is also scalable to a multi-server setup BTW.
For all intents and purposes, we're running Apache!
As for IIS ... well, I still don't understand why some folks voluntarily jump out of a perfectly working airplane, either.
PS. Why not make a clone of mod_proxy and call it mod_oacs?
(Just kidding 😉
Sorry to jump in and muddy the waters even more, but it's possible that, from a .LRN perspective, uPortal integration and some kind of a Sakai interoperability toolkit (like Java OKI bridge?) are more important than either Apache support or an easier installer. That's because the current state of Sakai creates an enormous opportunity.
Sakai is a tsunami. The amount of attention it is getting, both from universities and from vendors, is enormous. Major publishers are in discussions with Sakai schools about creating course cartridges. At least one synchronous platform vendor that I spoke to recently is giving serious consideration to integrating with Sakai in addition to Blackboard and WebCT. It is getting huge amounts of attention.
The trouble is that its feature set for end users is fairly weak still. I'm told that the plumbing is very good but a number of applications are either missing or just weak. If .LRN could "integrate" with Sakai (more about what that means in a minute), and were strongly marketed as having that capability, then I think you'd be able to get some real traction.
To start with, if the uPortal interoperability isn't already done, then I'd recommend finishing it. That by itself would allow you to claim some level of interoperability, since you could put .LRN tools into the students learning environment next to Sakai's through uPortal channels. Once you've done that, you could work selectively on adding back-end interoperability. It doesn't need to be full, everything, super-deluxe interoperability; it just needs to be enough to show that the community has both a strategy for and a commitment to making Sakai interoperability feasible. Intitutions who are attracted to adopt Sakai but are also concerned about lowering their risk of backlash from putting out a tool that isn't as polished as it should be will have an incentive to look at anything that can lower that risk by allowing them to plug in battle-tested functionality from a system like .LRN. So they'll be inclined to help finish Sakai interoperability work if it's already been started and appears to be a manageable project.
Once they are using .LRN for anything, you have an opportunity to compete directly with Sakai tools for pretty much everything. It's quite possible that some institutions will find themselves using .LRN for the lion's share of their environment and end up throwing out Sakai altogether. Others may take a mix-and-match approach long-term. Still others may rely on .LRN only as a short-term transition. But even in that latter case, you will have spread the good word about the toolkit and lowered resistance to taking it up for other purposes in those institutions.
Two caveats. First of all, taking on Sakai integration will do nothing to directly promote non-.LRN use of OACS in the short term, while Apache support and better installers both would. Second, I have little grasp of how difficult interoperability beyond uPortal integration would be and can only assume that it would be significant work. That said, one of the options that SUNY is seriously considering is running many of its legacy Lotus-based LMS tools through uPortal side-by-side with Sakai tools and swapping them out incrementally, so I know that mix-and-match is considered to be a feasible option for us. And in some ways, the marketing challenge of describing OACS interoperability with Apache may be roughly analogous to the marketing challenge of describing .LRN's potential interoperability levels with Sakai.
Yeah, why would anyone want to do this from a technical standpoint -- but if the political issue is "we must use apache" that might be a solution.
I beleive we did this once at ArsDigita - not the mod_aolserver stuff - that was unbearably slow with just one user.
And my more cynical side asks ... if the plumbin's really so good, then why are their applications so unpolished? :)
Couldn't be the old "java is so much better it takes twice as long to do anything" bugaboo, could it?
On the issue of integration versus building from scratch...as you know, I'm not a technologist. I could say that the technologists here at the SUNY Learning Network, whose kung fu I greatly respect, are not terribly worried about making mix-and-match integration work so long as all the components start with uPortal on the front end (including single sign-on support) and Oracle on the back end. But rather than just basing this on a battle of the experts, let's try a use case out and see where it gets us.
Suppose an organization using Sakai wants to add the .LRN learning object repository--something that Sakai doesn't currently have. What would it take to have some meaningful level of integration? Well, if all you had was the ability to display through the uPortal framework and identify users with single sign-on, that would be a good start. Professors could go into .LRN, configure the repository for the users and display the links from the repository in the Sakai class portlet.
Of course, you'd be asking them to administer two systems. What would be really helpful is if you built a bridge mapping the Sakai groups/classes to .LRN groups/classes. That way, a .LRN LORs instance could be automatically set up with appropriate permissions for the class.
I suspect that just providing these services, i.e., .LRN publishing to uPortal channels, .LRN acceptance of single sign-on, and mapping of Sakai groups to .LRN groups, would be enough to cover most basic application integration. (And correct me if I'm wrong here, but I believe that two of these three pieces are at least partially done.)
Suppose, then, that a university were given these three integration points from the .LRN community. What might they still need to add themselves to feel satisfied with our LORS integration scenario? Well, they might want to build a portlet for LORS administration so that the professors don't have to go to the .LRN class control panel that contains mostly stuff that they don't use. Not a huge job, right? They might also want to add integration with a grade book. But LORS supports SCORM, and any decent grade book application should also support SCORM anyway. So that's not a huge deal, either. I can't think of anything else, off the top of my head.
It seems to me that this is hugely less work than building LORS from scratch in Sakai. Am I missing something?
uPortal integration. If that's not the case I would love
to hear about it.
Michael, sure, integrating LORS as you describe might be a quick way to make that functionality available to a school, and might be relatively simple. But, what would it mean? In our thinking, LORS is not an end of itself, but rather a means to a end - importing/exporting class content. What is really the point of this if you don't have full integration of the community features of the underlying engine? I believe the kind of integration that would be acceptable to a school using Sakai would be to use our LORS as a front-end to import that content into their datamodel in Oracle.
Let's accept your opinion that doing this would be easier than writing a Sakai module to do the same ... what would be the result?
Inevitably, given the difficulty of maintaining multi-technology installations and given the religious beliefs, NIH syndrome, and the general emotional ownership psychology that comes from organizing, funding and being part of a large software engineering project ...
Such a solution would be viewed as being interim, only.
And what would be the advantage to .LRN of that? "We're the interim solution for LORS, foo and bar for Sakai schools that they plan to throw into the dustbin ASAP". I don't see that as a strong marketing message.
Underlying your posts lies the message that we've already lost the battle unless we graft ourselves onto Sakai's coattails somehow. If that's true ... what's the point of the battle? We could move on and concentrate on OpenACS proper.
Or those most interested in the e-learning platform could move on and become Sakai studs rather than beat the .LRN dead horse - I'm confident of my own ability to compete in any arena, after all. Of course it's not REALLY an open source project so perhaps we'd not be allowed in the front door :)
Now the funny thing is that .LRN is actually in a very interesting place. We have resources. We're not dead, yet. If we're dead in the US ... it's a big world out there.
A new non-profit's up and running and is funding some development. We have the e-lane project, funded by the EU (though not at Sakai levels of course).
Of course a major point to be made is that my opinion doesn't really count much, here. It's the .LRN board that should be addressing issues like this. You should probably consider writing an open letter to the board for their consideration (I'm not a .LRN board member).
'Don, let me start with your more "cynical side" first. I think you would come down strongly on the other side of the same argument if we simply substituted "AOLServer" for "Sakai" and "Apache" for ".LRN." If AOLServer's plumbing is so good, how come it has fewer mods than Apache?'
No, I wouldn't, not at all. AOLserver's not meant to BE an Apache.
That was by design. Right or wrong, available resources have nothing to do with it. They're just ... different.
Entirely off-topic but ...
Sakai was a totally fictional character, did they realize that when they named their project after an illusion? :)
Now that portal technology and SOIs have finally matured, they really change things. For example, up until now at SUNY, when we've needed new functionality in our LMS it's generally been easiest to build it from scratch in Lotus rather than find an existing tool and integrate it. Too much work, as you say. But in a uPortal/Sakai world, the integration points are much better defined and easier to handle. As we think about adding, say, chat, we're not thinking about substituting a third-party package for the short-term and then developing a "Sakai-native" package, whatever that would mean. Why waste the energy when we have so many other things we want to build? We're looking to find an "NIH" package that will do the job permanently.
The whole purpose of Sakai is to enable and support this sort of behavior. It's to prevent tool lock-in, to make mix-and-match a more feasible long-term option. The core developers hammer home the message that it's a framework; the applications that happen to come with it are just icing on the cake. So I don't think .LRN components would necessarily be viewed as a short-term crutch. It would be by some and not by others. But one of the main marketing messages behind Sakai is, "If you think the discussion board sucks, then swap in another one. No big deal." Here at SUNY, where we have to serve 64 very different campuses with one platform, and where maintaining a quick pace of innovation is important to us strategically, that's a message that resonates. We don't care what LOR we use as long as (a) it's the best one available for our constituents and (b) it plays nice with the rest of our components. Hell, we've been using Lotusscript and Domino for the past 10 years. You think Tcl and AOLServer are going to scare us?
As for the supposed implication that .LRN has "lost the battle," I am not implying any such thing. I wouldn't waste my energy posting here if I thought that were true. To begin with, there's certainly room in the market for more than one quality system. Ultimately, .LRN will likely occupy the space between Moodle, which is ideal for small schools with few development resources and lots of grassroots energy, and Sakai, which will theoretically be ideal for very large schools with significant development resources and a need for a tool that plays well with lots of other pieces of their enterprise pie. While there will be some overlap, I see Sakai, Moodle, and .LRN systems generally serving different market segments. Nothing wrong with that. Now, Sakai will probably be bigger that .LRN. Way bigger. Nothing wrong with that, either. While it's nice to be Hertz, Avis and Enterprise do just fine.
All that said, I am suggesting that .LRN and OACS can both benefit by demonstrating that they play well with other software. ACS was originally designed as a world unto itself back when there wasn't a whole lot else out there worth connecting with. It's an integrated application suite. But the world is different now. In higher ed, for example, universities want their LMS systems to integrate with their Student Information Systems (i.e., their electronic registrar software) and their university portals. You don't want to them to get the impression that .LRN/OACS are best used for either everything or nothing. Yet that's essentially the message they get when they hear "well, you're better off rebuilding from scratch rather than integrating." Of course, sometimes it happens to be true that they are better off building than integrating, and there's nothing wrong with being responsible and telling them so. But that answer should be a considered judgment based on a concrete use case and not a reflexive reply.
Integration with uPortal and Sakai are important for two reasons, one tactical and one strategic. The tactical reason is that there's a sales opportunity at the moment--a need that .LRN could fill by being first to market with tools that integrate with Sakai. But the strategic reason is to establish that OACS and .LRN don't promote lock-in. That they play well with others. It's not so different a reason than Talli's reason for wanting a better Apache message. The installer is a different story; that's a strategy that makes it easier to sell at the low end, where demonstrating that dealing with .LRN isn't going to suck up significant support resources is more critical. If you want to get into the larger organizations, having an integration story to tell is the way to go.
Presumably people keep bugging us to improve our applications ... forums, bloggers, etc ... and the Sakai people want to improve theirs because people use them. If all people want is LORS management and a gradebook, they don't really need either Sakai or .LRN.
The reason why people will look at .LRN kludged on top of the Sakai framework to any degree that requires integration with the Sakai datamodel as being interim has to do with administration. Professors and students (and presumably you) won't give a shit.
System administrators will.
Remember the first post in this thread? Talli complaining he's locked out of a potential major site because they won't even consider installing software that uses a webserver other than Apache. The reason here is that sysadmins by their very nature loath being forced to support additional software.
That would hold true for anyone administering a Sakai installation. Some might be willing to live in a kludged-up world, most would reject it if they have anything to say about it and will work hard to move past such a solution if they're forced to adopt it. In some universities IT departments have real power. Look at Al. Look at Sloan.
As far as integration issues go, in general we do much more integration than was true when you were involved in the community. You might check out some of the stuff that's been done.
And, again, take this up with the .LRN board. If any level of integration with uPortal or Sakai takes place, it will take place because the .LRN non-profit or one of its member universities funds it. It is really not an OpenACS issue. If the .LRN folk decide to fund it, the implementation will undoubtably be done by contractors in this community but it's not likely to be funded out of any of our volunteers free time.
Fundamentally it's a marketing decision. I personally don't see much value in the message that results from trying to chase Sakai. My own personal experience with my compiler technology firm leads me to think that if you start chasing a runaway bandwagon from behind ... it's hard to catch it and jump on.
From the technical point of view I'm neutral, and I suspect that's true of most of us in the mainstream OpenACS community. The people trying to market .LRN are the people who need to hear and evaluate your message. If it will help them to market the product and they feel it is worth funding, you'll find plenty of interest in the OpenACS community. If not ... why would we care?
- Create an "Apache compatibility" project area that consolidates current information about working with Apache. Announce that this project area has been created in the news on the OACS.org home page.
- As the first document in the project area, create a short piece that describes current methods for Apache interoperability (mod_proxy or whatever) and summarize additional methods under consideration or underway. Pay close attention to the language that you use to describe the current state. Make it positive but honest. Can you say that you currently have "interoperability" with Apache? Can you say that OACS can "run as a service" to Apache? Find positive statements that are true and will encourage interested parties to drill down into the meat of how this is true.
- If anyone in the community is using Apache and AOLServer together, even in very basic ways, list them in the project area. Actively solicit current and future use cases.
- When somebody asks, "Can .LRN work with Apache," answer "yes." Again, come up with an honest but short answer that gives a positive presentation of the true state of affairs. Don't get into the nitty-gritty details until they ask.
- Search for genuine, non-marketing and non-prejudice-driven use cases in which your current level of Apache interoperability support is not adequate. Are there things that Apache does but AOLServer doesn't? Is the current level of interoperability support adequate from a technical standpoint but inadequate for ease of use? Drive further development based on these use cases. And when you have an interested party on the hook such as Talli's entrepreneur, challenge them to show you how their Apache interoperability needs surpass that which is currently available in concrete ways.
To sum up, (a) declare victory loudly and immediately, (b) find a way to provide a positive but honest capsule summary of what you have now with a minimum of technobabble in it, and (c) create a content area on the site that demonstrates the community is serious about listening to the needs of potential users who have a strong commitment to Apache.
Note that none of this requires writing a single additional line of Apache compatibility code at this time. Anything else you do, whether it's FastCGI or Portable.nsd or whatever, can and should be added as developer resources allow; however, the community can and should declare that an Apache interoperability solution is available today.
Just my 2 cents.
But ... the success or failure of .LRN is much more dependent on marketing than technical details long-term. The kind of clients most folks in the OpenACS community deal with aren't going give them much insight into the workings of the academic mind. Of course many of us have been getting some insight through working with a variety of universities with .LRN, but with the exception of a small number we don't work within universities. And a large percentage of those who do work in universities outside the US, culturally very different.
So ... "we" (or more properly "I") don't care because the discussion's technically neutral. If someone wants to fund development of an integration package for uPortal or Sakai ala our LDAP integration package or the university registrar database integration package that have already been written for .LRN, it will happen. But "I don't care" because it's not a technical decision. It is a marketing and funding decision.
My guess is that at least some of the .LRN board and marketing/organizational people don't read the OpenACS Development forum and aren't even seeing this unless Carl or Al have asked then to.
Sakai and uPortal are both designed for this world. I understand the resistance that Talli faces, but I'm not seeing it here in my world. In my world, everything is about messaging. If the monolith we have called an LMS can be broken into pieces that can be mixed and matched based on best-of-breed decisions, and if I can selectively choose to get hosted solutions for some of those pieces rather than running everything off my own servers, this is seen as a Good Thing, and it necessarily entails being open to as many heterogenous pieces as are feasible from technical and business standpoints.
Look, I've said my 2 cents on this and really have nothing more to say on it. I have no dog in this fight. As a friend of the community, I simply wanted to point out what I see as a strategic marketing opportunity that is very much in the same spirit as Talli's call for a message/solution on Apache. Increasingly, supporting standard API's is the name of the game. OACS has a reputation as being an outstanding closed system. It behooves the community to change that perception by demonstrating some high-profile integration wins. Apache is one opportunity to do so. Sakai and uPortal are two others.
Take your pick.
"OACS has a reputation as being an outstanding closed system. It behooves the community to change that perception"
Why? The world runneth over with trendy lightweight web applications running over popular message APIs. Does this mean that the world of community websites based on a comprehensive datamodel is dead? I don't think so. Does this means our strategy of wanting to be the best in that world is the wrong strategy? I don't see why.
And trendy doesn't necessarily mean successful. Look at Craig's List ... some of the most primitive and untrendy community-building software on the planet, with a wretched UI. But look at that community and look at where it's taken Craig Newmark. And, oh wait, Craig's List seems to be pretty trendy today. People seem drawn to it. Could it be the fact that's its primitive UI is so dumb as to be impossible to misunderstand, and that its primitive community software support is just good enough?
Photo.net is no longer the pre-eminent photo website in the world, though it is still going strong.
However ... those sites which have come to be more popular, such as digital photo review ... are community websites, the same genre as photo.net and other ACS-derived community sites.
I don't see any evidence that demand for sites of this sort is slacking in any way. Yes, we need to be able to support popular APIs. As it happens we do support bi-direction RSS and webDAV and we will support more in the future. We're not quite as blind and stupid as you might think.
But OpenACS itself will always be an integrated toolset for building community sites. That's our niche. The other stuff you mention's cool and has its niche but it's not the entire world, no matter how exciting you find it.
You can wipe the spittle from the corner of your mouth now. You've succeeded in shutting me up.
My understanding of how to integrate with uPortal is that you produce XML, describe your state variables, and produce XSL to render your XML.
- Producing XML - we don't now but it was one of the goals of the templating system to do so and places where you can't do so because we are rendering html fragments in code are sort of broken.
- Describing state variables - mostly this is ad_page_contract for display pages, I am not sure what you do for complicated dynamic forms though. Good to do generally.
- XSL - well, I guess its not all good after all :)
I would also say that if we provide this sort of API code, people would find interesting things to do with OpenACS we have not even considered. Documenting what it would take to make dotLRN more "web service friendly" (as a source rather than a consumer) would be something that might spark real innovation, unlike Apache support, which might help adoption somewhat but would not produce interesting innovation.
It does not have to be a comprehensive solution either, a simple demonstration page which publishes a "class portlet" or exposing lors or something like that would probably be enough to get people who might care to pick up the ball and run with it. Worst case is that you produce something noone uses and best case, you get lots of interest from people who might not otherwise given openacs a second glance. It's an order of magnitude easier that Apache integration and I think is likely to be of more interest to people as well.
I found this the easiest way to take the variables defined in a Tcl file and turn them into an XML document. See https://openacs.org/forums/message-view?message_id=267842
By comparison the equivalent collection for OpenACS (tcl8.4, aolserver4 + modules, postgres8, and *all* of OpenACS including dotLRN) would be about 30mb (and just the binaries needed is 7mb or so). and that can easily be trimmed down to 15 or 20mb.
MIT was originally planning to transition to Sakai during Fall 2005. At best, MIT will be using a few "tools" from Sakai later this Fall. We are looking at least eighteen months to two years before Sakai will be production quality.
OKI is also up in the air. There is no commitment from MIT that it will be implementing OKI. It's mostly experimental at this stage and being put forward as a specification: whether it becomes a standard remains to be seen.
There is also no agreement yet on how uPortal, Sakai, and OKI will work together. Moreover, Sakai has yet to deliver any real code. What they are calling "Sakai version 1" is recycled code from Michigan as part of the Chef project.
I think it's a waste time to spend our energies worrying about Sakai and OKI right now. When they deliver something, let's take a look.
I wouldn't yet discount .LRN playing in the enterprise arena. For example, Valencia has 20,000 users and growing to 40,000. We also now are beginning to have a strong integration story. We have written a web services based interface to DSpace, which is being adapted --- even as we speak --- as a repository for learning objects at MIT. There is an external authentication module. We have internationalization. And we also expect to have a connector that works with registrar systems.
If you want to drive an SUV, go for Sakai (whenever it comes out).
The most important thing about OpenACS/.LRN is that it follows an open source development methodology. Sakai is closed source development. I will put my money on OpenACS/.LRN.
And I've always supported efforts to integrate support for various interoperability APIs - remember SOAP? webDAV? RSS?
I'm not arguing against API integration where it makes sense.
But is that all it really takes to supply a complete Sakai-compatible application? If so, I'll STFU ... we probably integrate with their superior plumbing with far fewer than 20 full-time developers.
"You can wipe the spittle from the corner of your mouth now."
Pardon me for assuming you think I'm stupid and blind, rather than rabid.
I'm mainly annoyed at you because, as I've said twice, marketing/positioning discussions regarding .LRN should be addressed to the people who make those decisions.
They get to decide how they want to position .LRN and they have the responsibility of achieving funding to achieve those goals, both in the technical and marketing realm.
I have no problem with sound marketing decisions driving the technical direction of .LRN, and of course in every instance our goal is to fully integrate anything done for .LRN into OpenACS proper. If .LRN drives further efforts towards interoperability, great. If we had effective marketing of OpenACS proper (as opposed to effective sales to individual clients), I'd feel the same way. That's why I thanked you for your excellent summary regarding Apache.
I must say it is a bit annoying to have you, after a very long absence, jump in and say, in essence, "this is what OpenACS must do to succeed" in a tone that is somewhat lecturing, to say the least.
My postings are not intended to be critical. Given finite sources we need to focus. From a technical perspective the Board identified an "installer" as the highest priority. This, of course, does not preclude the community from considering new ideas and discussing options.
Talli...I am sorry that your original topic got hijacked. But it has stimulated a good discussion on priorities.
Al, Michael ... in regard to .LRN marketing/position/futures, if Michael were to be added to the .LRN marketing forum on the .LRN site, then his comments *regarding .LRN marketing/positioning* would automatically target the right people.
Michael ... Danielle Hickey tried to start a thread on Sakai there some time back without success, I'm sure she would've greatly welcomed your input.
The issue of running behind Apache (or IIS for that matter) is really just an integration story. If we can answer that than we're fine. I'm not sure that mod_proxy does, of course, and would very much like to hear the data that Peter has regarding scalability with such a solution.
To be just a little more revealing, the conversation I had was with the CTO of one of the major p2p service providers. This was a site that got many millions of hits per day with a very complex web architecture built around and behind Apache. Such a set up would not be unlike what sysadmins at major universities might create in order to run their very complex systems (SIS, LMS, etc)
So as far as I can tell, this discussion is all related.
Please continue. Nice to see all the old hands return to engage in some polite but passionate discourse :)
In Valencia we are fully experienced with Apache
web server and the choosing of aolserver / dotlrn
has cost much effort (both for technical and political reasons). In my modest opinion much people leave therefore
use / test the platform by the need of use a foreign Web
I have listen to the use of mod_proxy to integrate
aolserver with apache. What could we gain using
a Apache frontend to aolserver with dot?
- I think that running under Apache will remove a big barrier that currently prevents people even looking at OpenACS. Your average CIO and developers will immediately ignore OACS because it is too non-standard. Running under Apache makes it seem a lot more familiar. Anyone who thinks this is not true has not met any average CIOs or developers lately.
- If an organisation commits to OpenACS however, it won't be long before they switch to AOLServer. But the Apache support was worth the effort because otherwise they would not use the product.
- I currently develop very intensive OO and templated Perl code that runs under mod_perl/Apache. I have written code that interacts with Apache in much more complex ways than appears to be average in the mod_perl community. Given that, di I think Apache is more flexible etc. than AOLServer? No way. In fact our team is seriously considering writing the server daemon in Perl itself because there are no ways around some core issues that we have without writing C code. I wish AOLServer was an option, but there is no way we would get permission to use it in our customer production environment. Another team, however, got the go-ahead to deploy Tomcat under Apache. Anyone who has administered Tomcat knows how much that sucks, but it sounds ok to the people making decisions because it's Java, and it comes from the Apache foundation so it must be good.
Look at Postgres vs. MySQL - if you don'at least _appear_ to support the platforms people want, you will lose to an inferior competitor every time.
Selling TCL is hard enough these days (not even Vignette can get away with that any more) - Apache support would really help with marketing.
I also think it's a bit of a low hanging fruit too - compare it to re-coding OpenACS in OO Tcl or in Ruby...
Not sure I added any value there - sorry to waste your reading time ;)
Very true. Let's assume for the sake of argument that we all agree with the statement. I have several questions.
First, what should be the technical approach to make this happen?
Second, what kind of effort is required (i.e. how much will it cost)?
Third, is there expertise in this community to carry out the work?
Al, I believe the above answers all three of your questions. Although taking it from prototype to production might require additional AOLServer hacking skills (as will support), I suspect those exist in this community. Also, given FastCGI's age and stability, I suspect that the support load will be quite manageable once the initial work is done (unlike mod_aolserver etc)
FWIW, I think the only way to productively move portable.nsd forward is for someone with _specific_ requirements to underwrite it. Basically, it needs a client/project so that you can decide how (un)important some of the lesser used AOLServer/OpenACS functionality is and you can productively narrow the scope. Supporting the entire legacy API required to run all of OpenACS doesn't make sense when it's often easier to rewrite legacy/deprecated code in more modern/supported idioms. I discovered that supporting OpenACS via portable.nsd is an overwhelming task compared to supporting a specific (and ideally, recently written) OpenACS application. For that reason, I'm more optimistic about Dossy's prototype which he said he'd deliver sometime in March.
Talli et al,
I've read that one recommended way to scale mod_perl is to separate out static web serving from the dynamic part (which people have proposed here with pound/thttpd?). You run a front-end Apache instance with mod_proxy and a heavy-weight backend with mod_perl. I suspect that recommendation is good anecdotal evidence that the reverse proxy overhead is negligible. I've never had a problem with it, but haven't deployed it under extreme load.
FWIW, I think the only way to productively move
portable.nsd forward is for someone with _specific_
requirements to underwrite it.
I think John nails it here, assuming such a client exists. It seems like most of the discussion is not so much about whether we'd like to integrate, but rather the conditions under which to undertake the effort.
If running as a mod_* has value, someone ought to be willing to pay for it. Having the consortium pay for it as a purely research effort is less than ideal, imo. In the best case there would be a client driving the project with specific requirements and a specific timetable.
Perhaps the consortium's role is to help identify such a client and provide some level of funding. "You like .LRN. Your IT folks say it must run under Apache. It can. We'll help."
Incidentally, and without discounting the valid marketing points about Apache/uPortal/etc, we mustn't forget the value of competing on features. In addition to asking "how can we get people who require Apache to adopt our software?", we should always be asking, "how can we make our software so compelling that they're willing to overlook the mechanical details?"
But from a marketing perspective, the most important thing is to declare victory. Think of it as the marketing parallel to agile development. You have a solution. It may not be the fanciest solution in the world, but it's still a solution. Call it that. Add elements to that solution iteratively as needed. Each addition generates a press release, showing movement on the project.
And actually, the same thing could be done with Sakai. Providing uPortal integration does, in fact, provide a level of integration with Sakai in and of itself. It sounds as if, in principle at least, most folks think uPortal support is a good idea but opinion is more mixed around Sakai-specific support. If you finish the uPortal support, you can say that the .LRN community "provides Sakai integration through uPortal and is studying the value and feasibility of providing further support through OKI and and Sakai-specific APIs." If, on top of the uPortal work, you gather the bits of information that Andrew and others have gleaned in terms of looking at OKI integration into a white paper, you will have what looks like (and actually is) substantial work toward serious Sakai integration, even though you haven't written a single line of Sakai-specific code.
At that point, no more work need be done. Serious potential customers should see enough to demonstrate feasibility. You add support as market demands, developer resources, and sales opportunities dictate.
This is an example of a situation where Apache integration via (say) mod_proxy makes sense from a technical POV. No one rationally expects to avoid the need to integrate with the existing architecture in this place.
As far as getting "first looks" from people who are simply put off by our non-standard software stack ... is Apache+AOLserver+Tcl+Postgres really going to appear more standard than AOLserver+Tcl+Postgres? I just find that hard to believe. They're still going to say "Ugh, AOLserver" and "Ugh, Tcl". Postgres is no longer, I think, much of a barrier, it's well-respected and gets lots of ink theses days.
So pushing for an integration solution and touting our ability to do so makes perfect sense ... but will do little to overcome resistance to "non-standard" software. IMO.
That's why I think making it possible for people to try it out with as close to zero effort as possible is more important for getting "first looks" than Apache integration. Our Knoppix disks, graphical Windows installer, installers for common Linux systems, etc. If we could afford it, I'd say just put one of those cute Mac Minis on their desk and say "just plug it into your network" to give folks their first hands-on experience.
It sounds like the .LRN board agrees with part of that, at least, since Al mentions installers as being an identified board priority (and they did not get that from me, I was not part of the discussion).
I think that's correct.
As i mention above, investigation into uPortal integration gone s back a least a year. Interest among our tech community dropped off as interest among those making .LRN funding/strategic direction decisions dropped off. AFAIK there was no resistance among our tech community to the notion of doing .LRN integration with uPortal, that wasn't the reason for it being dropped from the agenda.
Perhaps Al can speak to his feelings as to the importance of uPortal integration. I've assumed the past many months that it's just been a matter of prioritization, with uPortal integration not making the cut given the funding and resources available...