Forum OpenACS Q&A: Re: Will Dr. OpenACS survive? Or why I stopped worrying and learned to love the .LRN consortium?

Wow.

This community is amazing.

I've learned a ton from this thread. Thank you for replies to my questions, those are enormously helpfull.

From my naiive point of view XOTcl sounds/reads like the cleanest way to add the OO capabilites to the framework. And I agree, the sexiness part really should focus on the look and feel aspects of the project. One of the things that really attracts me to OACS is that there aren't bindings for every language under the sun - while I am a huge fan of Python, after learning and reading about OACS/AOLServer, it is clear that Tcl strikes the right balance for the category that it's playing in (more or less). When I install OACS, I know I don't haveto worry about compiling modules, debugging configurations, tracking down esoteric bugs just because I want to run say a calendar application from the repository (as an example). One language, one server, all done pretty much right.

I think the greater consideration is thinking in terms of application "scale". I would think that comments about java callbacks would add the greatest ability to scale beyond the frameworks current scope. Things like Perl, Python, etc, simply do not seem to have a scope much greater than what Tcl/XOTcl would provide anyway (outside of maybe the huge number of libraries, yet still, no one in their right mind writes stuff in Perl and Python where Java is called for). It would seem to me that Perl and Python support would scale OACS laterally moreso than vertically, whereas Java would allow the platform to scale both laterally and vertically simultaneously. The only question that arises from the java proposition is, just how much scaling do you need - if you want something that extends OACS so far beyond what it was designed for, perhaps one would of taken that into account in the first place and started with Java in the first place?

Hmmm ... this topic is very quickly getting me in over my head technically. I guess just count my vote in toward XOTcl as a solution that appeals to me on aesthetic merrits in relationship to the big picture

As a side note, it would be neat if we had the ability on the site to break discussions like these into a workflow and start hammering out some details. Say something as simple as Volunteers, Proposal/Specification, Vote/Feedback (inclusive of forum), Project Subsite, Organization of Task ( why isn't Project-Open.com on here? ), Progress and Bug Tracking, Publish. Perhaps there is one that I'm not aware of?

*sigh* so much to do, so little time.

Some tiny notes to anyone considering look and feel proposals for OACS ( I am planning on jumping in as soon as I get the hang of creating simple applications here ):

- this needs to be an official project with a project manager, perhaps listed under the projects directory, perhaps somewhere else as a special project (can this site be a project it self perhaps in the same way .LRN is?)
- start small, no big changes.
- the layout should stay mostly the same for the time being.
- incremental layout changes are better than huge changes as they let everyone 'fine tune' the site rather than invest huge amounts of energy into a site upgrade and then haveto live with it for a year or two.
- the site should remain 100% wide
- start by changing the colours, css, and fine tuning some of the visual cues such as colours, sight lines, links, etc. first.
- an alpha/beta replica should be available for public viewing/comments
- all workfiles should be available in some repository (preferably using Gimp, yes it is good enough to replace PhotoShop), such as CVS/SVN so that anyone can pick up the work where it left off, and incrementally push the look and feel forward one small step at a time.
- keep the logo for now. a logo change is huge. people may not like alex, but then again, when Tux was proposed as a mascot for Linux everyone thought that was stupid too. If a logo change is needed, I think that should be handled properly and not rushed.

This will keep the project from being overwhelming, and allow for incremental upgrades.