18 Jan 2007 – octane x mstreet
Tonight, Alex and I met at Octane. DJs were funky, not too loud, louder.
Mark called us up to his place at MStreet, college people and Jason were there.
What we worked on:
Alex- Proposed a problem as a potential GMaps hack (more below).
Graham- Adding VM status functionality to ChucK firefox plugin (XPCOM).
Mark- Porting OpenSoundControl to Mozilla via XPCOM.
Jason- Adding new features to his Q&A site startup, Qaboom. (smileys in chat, etc)
gmaps-
Alan Turing, Charles Babbage, Ada Lovelace, and n-3 other computer scientists are in a running club. They need an application to determine the most fair meeting point (similar to the centroid for street distance), so that they all run an equitable amount to reach the meeting place. Alan is a stronger runner than Charles, so we can expect him to be able to run farther by some scalar, like 2. Our algorithm should take this into account.
xpcom-
Both Mark and Graham were having binary build problems with XPCOM. First, we both had an issue with xpcom_Glue. G solved it only linking xpcomglue_s.lib (instead of that and xpcomglue.lib) into his binary. M solved it by building his project with more recent Makefile as a starting point. Sometimes one wishes the C++ compiler could be a little less literal.
XPCOM is in general a neat toolkit for making cross-platform software, it is not without its pitfalls. Several great resources are informative but contain out of date elements (book, component tutorial) with nods to the changes only in web accessible mailing lists. Since this is open source, some of the burden falls on us to update the materials. (Maybe M and I can do that after we finish our components.)
An application or applet has many components end-to-end, in different languages and systems. Possibly you will have binaries in C++ XPCOM, scripts in javascript, chrome configuration in RDF, and UI specification in XUL. Starting a project and debugging is therefore an extra-long chain of getting little things wrong until you start getting them right, and tutorials are long and laborious. On the other hand, splitting the effort between subsystems seems more flexible. It would feel wrong to put the config or UI stuff in procedural code, or the scripting stuff in binary. Startup time vs. flexibility, probably a reasonable tradeoff.