I lean more in Michael's direction than Don's. Not because
I care much about Sakai or uPortal but because I think the things
you need to do to interoperate with them are good in and of themselves. I think of it as being "web services friendly".
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.
