Symphonious

I found an unexpected source of frustration while getting LiveWorks! online. The site is primarily an instance of WordPress1 but the mailing lists are handled by Mailman and the archives by Lurker. All three of them are simple to customize their outward appearance, but all three of them use a different template language. So now instead of having one site design, I have to have three very similar looking, but completely different design implementations2. Every time we want to update the common parts of the site, we have to do it in multiple places in completely different ways.

There must be a better way to do this. It's great having all the power and flexibility of PHP in Wordpress's templates, but most themes don't need it. Isn't is possible to come up with some simple template standard to at least allow the common structures to be shared? The specifics of the page content will still need to be done for each program but that's fine.

At the very least, could tool vendors that provide a web interface at least make it use HTML 4 and CSS or better?

1 - purely because it was the easiest thing, I'm not really sure it will scale as the site expands↩

2 - actually I wound up with only two because I left Mailman as-is as just highlighted the email interface instead of the web-based one↩

It's taken quite an effort to get everything up and ready to go, but just in time for Christmas we're ready to announce the availability of Ephox LiveWorks! The grand plan is to give our clients and the public in general better insight into what's going on in the Ephox labs and give them the ability to shape the company's direction.

The site is starting off small, with just a few neat little plug-ins for EditLive!1 available and a mailing list, but I'm really excited about it. Ephox's products are used by nearly all the big name CMS vendors, so the direction our products takes has a huge impact on the CMS industry as a whole. Getting more people involved with that process is going to make a big difference. We're hoping to ramp up the site over time, following what user's want, but we're thinking along the lines of early access releases, providing integrations into open source systems and eventually weekly builds of our products to let our clients take advantage of new functionality as soon as possible.

If you're interested in content contribution, editors or the CMS market in general, I'd suggest you at least lurk on the mailing list to keep abreast of what's happening. It will take a fair while for it all to ramp up so I certainly don't expect to see much activity but I can see a lot of potential and I'm really excited.

Check it out and let me know what you think.

1 - like the one that lets me use these seriously cool footnotes…↩

Ephox took a couple of leaps forward today in terms of being more open and accessible to our clients. Firstly the planet instance that I've had running as a proof of concept for a while has been moved over to an actual Ephox server and is now at http://planet.ephox.com/ If you're subscribed to the old feed your client should automatically switch to the new domain now but please do check it as test.symphonious.net will probably go away at some point.

The other improvement is that we now have a blog specifically devoted to notifying our clients of new releases. It's at http://releases.ephox.com/ includes the change log for each new release and is syndicated via Planet Ephox as well. So if you use Ephox products, make sure you subscribe to that blog and keep up to date with the latest and greatest versions. You can get email notifications of releases from there as well thanks to FeedBurner.

I've learnt way more about mod_jk in the last week than I ever wanted to know. Apparently the configuration is completely different between Debian 3.1 with Tomcat 4 and the current Debian testing with Tomcat 5 (point something). Why the mod_jk package doesn't just do the configuration for you is beyond me, or at least have a debconf wizard to do it.

Anyway, with Tomcat 4, the magical directive that makes deciding what to delegate and when simple goes like:

<Location /JSPWiki>
    JkUriSet worker ajp13:localhost:8009
</Location>

You, in theory, should be able to achieve the same thing via the workers2.properties file stuff but I never got it to work. The advantage of JkUriSet is that it embeds neatly into your apache config so you can nest it in a virtual host and it does the right things. You still need to futz with workers2.properties to tell it where the tomcat instance is, but that's fairly simple if you start with the examples.

The internet connection started working at my new unit today. Shiny new ADSL2 connection so no more 1500k connection limit for me. Technically my ISP doesn't know it's up and running yet so they haven't activated the VOIP line that's bundled and the connections capped at 3000k which is what it's happily connecting at. In the next couple of days that should get sorted out and it will jump up to a cap of 24000k. It remains to be seen how fast my actual connection will be given the poor quality phone lines generally found in Australia.

Even so, the difference is really noticeable already. Everything's snappier. Doug, you are seriously missing out. :P