I’m (re)working on the learning object presentation code in CAREO. It currently uses a java class to figure out what sort of stuff it need to do to present a resource associated with a learning object. Some quasi-hackish code, like “if it claims to be a QuickTime movie, double-check the technical.location file extension. If that checks out, assume we’re really talking about a QuickTime movie, and try to build a page to display it. Unless it’s been uploaded to the ALOHA-managed streaming server, since that will already wrap a page around the file. In that case, just display the file as-is. Otherwise, go ahead and generate a web page, and add the object/embed tags to set up the QuickTime plugin. Feed it appropriate parameters, and return the page.”
That goes on for other file types, checking file extensions and technical.format, not really trusting either. If the metadata is entered incorrectly, and someone provides a technical.format of something like “It’s a Quicktime Movie” (I actually saw this in the repository!), I need to do stuff to fall back on displaying it based on filename extension. Assuming THAT is correct and standard…
I’m hoping to build an XSLT-based metadata presenter, that will respond to the schema used to store the metadata (IMS 1.2.1 vs. CanCore, vs. IMS CP 1.2 etc…) and build a page to represent the asset/media associated with the object. If it’s a content package, I’ll also need to generate a table of contents or menu of some sort.
It looks like the CVS client built into ProjectBuilder insists on puking all over the deeply-nested file structure of a WebObjects project. Folders that are actually packages, etc…
In 3 separate cases, although PB insisted that all files were in fact committed to CVS, and up to date, only the .java files were uploaded to the server. Using the manual command-line CVS client, I was able to commit the whole shebang. Very unnerving. I’m going to revert to the command line client for the time being, and play around with Concurrent Versions Librarian (CVL), which is a gui-based CVS client for a bunch of platforms, including MacOSX. It looks like it needs a bit of tweaking to get it configured right, but I figure I’ll be more likely to commit regularly (and properly) if I don’t have to keep looking up commands and codes for cvs and vi.
There was a pesky bug in CAREO for the past couple of months, where a non-themed component with a hyperlink would nuke the theme setting for that session, possibly also improperly rendering whatever page was linked to the hyperlink.
I’ve finally tracked it down and squashed it (it was low priority, mostly cosmetic), and it seems to work better. Theme setting is now properly stored in (and retrieved from) the session, so hyperlinks should work more reliably (like, for instance, in the WOTabButtonPanel in Metadata view).
Just got this fun error message while trying to build UCRepositoryCore after making some changes:
Of course, that means that when I re-open the UCRepositoryCore.pbproj file, it’s going to insist on rebuilding the index. Again. Including the entire known java universe. Again. Grr… Another half hour at 100% CPU waiting for that to finish…
Just came across a great term on Tim Bray’s ongoing site: Development by Accretion. He used it as a throw-away comment when talking about something else, but it struck a chord.
From Tim’s posting:
I ended up having to write some real dodgy ad-hoc code to discard the right-side apparatus in certain poorly-thought-through special cases. Hmm… I don’t want to write a bloody soup-to-nuts editorial system by accretion, but the slope is feeling slippery.
Unfortunately, this model of development will tend to happen on projects that are under time or resource constraints (and what project isn’t?). CAREO is guilty of this, which explains the refactoring post yesterday. Ideally, we’d stop active development for a month or so, break the code into better-organized nuggets of goodness, and document the works. That would at least mitigate the nightmare of accumulated accretion.
Interesting article on Meta-time discussing some of the big players in the LMS game. They ignore many of the small guys, which seem to be positioned to fill the gap between the insanely expensive Enterprise-class LMS vendors and the roll-your-own solutions.
I think it might be relevant to add this to the discussion: If you build your content to known standards (like, say, IMS and SCORM), it DOESN’T MATTER which LMS you use, as long as it’s compliant, too… Want to switch LMS? OK… Just export your content and data from the old LMS, and import it into the new one. IMS is doing a lot of work on filling in the gaps on the standards, and we should all be leveraging that work.
Spent much of the afternoon refactoring some WebObjects components in CAREO to let me better reuse them as bits of themey goodness. Stuff like Search Results, which is currently a single Page wrapped in the PageTemplate, will become 2 separate components: a reusable component to display search results from any query, and a standalone page to wrap that reusable component to reproduce current behaviour. The big push for this is the SciQ zones, which will have all kinds of search results all over the place, with a need to customize the design of each page.
Also spent some time refactoring the theme definitions, to let me add preferences at the theme level. You will be able to override the default username and password, and possibly all kinds of funky stuff, stored in an NSDictionary in the Theme table in CAREO. Could be cool…
Here’s some of the XML databases we’re looking at here, in no particular order:
Exist
Current front-runner. Cheap (free), implements XPath, with nice ties into XML-RPC and JSP. Implements the XML:DB interface too. Seems fast, but wondering how it will scale up, or react in a “real” environment (outside of the test apps that ship with it). Rob is investigating this now, and has a copy of our entire metadata repository stored in it as native XML files. It has a cool file structure metaphor, so it’s like SSH’ing into a box to browse files and run queries.
NOTE: I had originally incorrectly stated that Exist implements XQuery. I meant XPath. XQuery is listed as a possible future feature for Exist, but it is not currently supported.
Xindice
Was the early frontrunner, but was too dog-slow to use.
Tamino
Was the original second choice, but is waaay to expensive, and only runs (well) on Windows servers. We need to be able to deploy on anything, especially MacOSX and Linux. Has amazing technology, though. VERY fast, dynamically indexed, etc… Very impressive stuff, but it’s too bad their sales reps were so darned arrogant. “MacOSX? NOBODY is using that! If you want an easy install, just install linux on an old P3. That would work better.” Thanks…
Sybase
Looked at WWDC2002, but XML support wasn’t cooked yet. Am looking at it again. Hybrid SQL/XML database (but sounds like they are stored as separate beasts).
Oracle.
Too freakin’ expensive for us.
Openlink Virtuoso
Haven’t looked at it yet, but sounds cool. Hybrid SQL/XML database, and it sounds like you can run SQL-ish things on XML, and XQuery-ish things on SQL… Odd?
I just upgraded to Java 1.4.1, and all seems great. jEdit is much more responsive, and the SCROLL WHEEL WORKS! YAY! It’s SOOO much faster than 1.3.1 was, and this is without the hardware accelerated SWING (I’ve got a pokey Powerbook G4/400, and the video card isn’t up to snuff for that).
It’s interesting that although 1.4.1 was rumoured to be a from-the-ground rebuild in Cocoa, the Services menu still doesn’t seem to work from within java apps. Hrm…
The only drawback I’ve come across so far is a minor nitpicky thing. ProjectBuilder insisted on rebuilding its class index when I opened CAREO in it. Took almost 30 minutes, and indexed SWING et al. CPU was running at 100% the whole time, too. I just KNOW that when I open UCRepositoryCore, it will insist on re-indexing the entire java world again. Doh.
UPDATE: Yup. It’s re-indexing the entire known Java Universe… Oh, well…
