Forum OpenACS Q&A: offtopic: InterWorld experience?
has anyone had experience with Interworld? (http://www.interworld.com) They make what looks like another toolkit for building DB-backed sites. It seems to have been used by a few large clients (http://www.okidata.com)
It is closed-source, but it looks to me like the company might be in its death-throes ( http://finance.yahoo.com/q? s=ITWR.OB&d=c&t=2y&l=on&z=b&q=l ).
I was wondering if anyone had actually worked with their stuff. Is it any good? Perhaps there are some ideas (data model, etc.) that we can take away from their product, and incorporate into openacs.
I've actually emailed the folks their to see if they'd consider GPL'ing the code. (going from a market cap of $4B to $500k in 15 months might make them want to reconsider their current business model...)
So.. anyone out there played with this thing?
Don, I know a company that has trademarked, "Information for Everyone." Talk about double talk...
Has anyone played with <a href=http://www.masonhq.com>Mason (http://www.masonhq.com)</a>? It seems like an OpenACSish product in Perl. From what I understand, it defines an API. But that's about all I understand.
However, Mason is primarily an API - while a library of code is beginning to appear, it's nowhere near as rich as the one you get with OpenACS (which is why I've done some work on generating a Perl API to access the OpenACS datamodel). The datamodel and library of code in OpenACS is IMO the most compelling thing about it.
(For those wondering about autohandlers and dhandlers:
An autohandler is code executed upon every request to the site hierarchy living below it. By calling itself as a method operating on the pages, you can stuff all of your framework in the autohandler and everything in the directory tree under it need only be the content specific to that page.
dhandlers provide a convenient way of mapping default behaviour to a hierarchy when files corresponding to requests aren't available. One example would be a news site, where a request to /breaking/news.html would grab news.html if it was present, or gab /news/dhandler if it wasn't.
Since you can also trivially extract URI components from a request, your dhandlers can do nice clean variable passing - for example, for stories on our news site, we might have an /archives/dhandler. Pointers to old stories might take the form /archives/2001/2/32/greenspun, at which point the dhandler is invoked with 2001/2/32/greenspun passed as a variable. Do a split() and you're ready to populate your DB request, and silly spiders and proxys that refuse to handle GET requests in an RFC compliant maner are fooled.
But nothing's worse than a lanuage war, I'll simply say that one mans' sugar is another mans salt.
(Actually, I like salt, so perhaps that's not so appropriate...)