December, 2005 Archive

We have been considering migrating Xaraya to the creole abstraction layer in the future. Creole is similar to the adodb library we use now. Originally the support for Creole was created to be able to implement a MS-SQL proof of concept quickly. After using the library for a bit I found it much easier to work with than adodb. Creole’s API is much cleaner and it is PHP5 only, which gives us a head start for future Xaraya versions.

The monotone setup we use allows us to test all this without disturbing main line development. Organizing these bigger changes into scenario’s allows us to isolate these changes and see where they lead to. The decision to use or to throw away can thus be postponed to a time when we’re ready to do so.

Since replacing the middleware is potentially a very big step, I noticed we (the Xaraya group) have some trouble making a decision on what to do with this. Therefore, the creole scenario has been merged into this site to show that a real life site (albeit a small one) can be migrated to creole without any effect. (Note: I’ve been running creole on other installs for a while now, so I’ve known this for a while)

Verdict: one change was necessary to wrap the ‘GetRowAssoc’method present in adodb but not in creole. Everything else worked directly after the merge, so my preliminary conclusion if the decision hangs on ‘what impact does this have?’is that the impact is very minimal. On top of that I think that the issues we might run into are not bad things as such, but chances to improve Xaraya.

Creating content with Blocklayout in Xaraya is flexible and every once in a while i want to take it for a spin. In the past i’ve played with creating a XUL theme where Xaraya served it directly as the XUL mimetype, this time i’ve been playing with creating a calendar feed of any Xaraya content which has some sort of a date attached to it.

What happens is that the content of some part of Xaraya is fed into an iCal theme which produces output according to the iCal standard Blocklayout sets the right content type for us, which allows clients like Apple’s iCal or Gnome’s evolution to ‘subscribe’to the calendar feed.

Above is an example on how that could look in the iCal application. The Feed block on the right side allows you to do exactly what is described here if you have a client which allows you to subscribe to iCal feeds. I’ve tested it with Evolution and iCal. The concept is still young but I can see a lot of potential in this.

We run about 30 Xaraya installations for our clients on our servers. Some of those clients are eager to migrate to PHP 5 while others are more conventional and want to wait. For others, due to the specific requirements, moving to PHP 5 is not possible yet. How to cater for both of these customers?

Assuming it’s common knowledge that if you want to run both php versions on the same server you’ll have to run two different instances of your webserver, usually on two different ports. In our case, when you access a site you get apache 1.3 with php4 by default. If you access the same site at port 81 (like site.com:81) you get apache 2 with php5.

When you want to make sure that a particular site runs php5 even if accessed through the default port (80) you can include the following in your htaccess file:

# Force this site to use port 81 on which php5 is served
RewriteCond %{SERVER_PORT} !81
RewriteRule ^.* http://marcel.hsdev.com:81%{REQUEST_URI} [L,R=301]

The first line tests whether the port accessed is NOT port 81 and, if the case, redirects the browser to the same request uri, using the 301 status code (“moved permanently”) and makes sure it is the last rewrite rule

This setup allows each individual site to decide whether to run on php5, optionally using bleeding edge Xaraya features like the creole scenario (which requires php5 ) or to server on both php4 and php5. Likewise if you want to prevent using php5 it’s easy to see how the htaccess could be adapted. This situation is however far less common.

Emerce – Technologie nieuws: TiVo maakt downloaden naar iPod mogelijk:

De Tivo-dienst is officieel alleen beschikbaar in de Verenigde Staten en het Verenigd Koninkrijk. In Nederland bestaan ook TiVo-gebruikers. Wie het apparaat hier wil gebruiken moet wel flink sleutelen aan het oorspronkelijke apparaat. De Nederlandse TiVo-gemeenschap assisteert hierbij

Translation: “The TiVo-service is officially only available in the United States an the the United Kingdom. In the Netherlands there are also TiVo-users. Who wants to use the device here, has to perform quite a bit of tinkering with the original device. The Dutch TiVo community has some useful info.”

This community site was started by Dennis and myself. Lately Dennis has done some great work making it easy to create a fully working TiVo in the Netherlands. The critical point is having high quality guide data. Dennis runs a Guide Data server for the community. Several others, including me, run their own emulators for further development.

While it would be great to have an official TiVo service in the Netherlands, it would also destroy the community as it exists today, because the moment an official TiVo subscription can be had, our efforts become illegal, not only by the way TiVo license it hard- and software, but also by the licenses imposed by the several TiVo groups themselves. Most of the open tools developed have an explicit mention you can only use them if there is no official TiVo service available in your area”