Don't call me DOM » Development

WebIDL checker

Dom — Thu, 30 Jul 2009 07:14:54 +0000

A growing number of W3C groups are in the process of developing JavaScript APIs: the HTML Working Group, the Web Applications Working Group, the SVG Working Group, the Geolocation Working Group, and the newly created Device APIs and Policy Working Group of which I am one of the Staff Contacts.

The Web Applications Working Group has been developing a common IDL format to define these APIs, called WebIDL, which basically takes the OMG IDL format and extend it to make it more useful and informative in the context of JavaScript APIs.

In the context of the development of the OMTP BONDI APIs that will serve as input to the new Device APIs and Policy Working Group, an OMTP Member, Aplix, developed and released under an open-source license a tool called widlproc that checks the validity of WebIDL interfaces, and turns valid fragments into an XML format.

I already have plenty of ideas on how to exploit that XML serialization of WebIDLs, but as a first step into the world of WebIDLs, I have developed and set up on-line WebIDL checker that provides a wrapper around widlproc. You feed it with the address of an HTML document containing WebIDLs and it:

automatically extracts WebIDLs fragments from an HTML document (using XPath),
verifies the validity of these fragments (through widlproc),
outputs error messages when finding invalid fragments,
outputs an HTML representation of the APIs otherwise (by applying an XSLT style sheet to wildproc output).

Some examples of results:

on the 140 WebIDLs included in the HTML 5 specification (where it would have detected the bugs I reported earlier by running widlproc manually on the spec)
on the latest draft of the GeoLocation API
on the Camera API proposed by Nokia for the Device APIs and Policy Working Group – where the tool reports an error for the use of the sequence keyword that hasn’t made it yet in the official WebIDL spec (but is defined in the editor’s version) and thus isn’t recognized by widlproc yet.

It is clearly a niche-tool – how many people on earth are ever going to write a WebIDL ? But hopefully it will help in detecting bugs in WebIDLs produced by W3C groups and others.

Using /etc/xml/catalog with org.apache.xml.resolver

Dom — Thu, 16 Jul 2009 14:50:30 +0000

I have just reported the bug in the w3c-dtd-xhtml Ubuntu package that had prevented me from using the Apache XML Catalog resolver to use local XHTML DTDs rather than the on-line ones when using the Saxon XSLT processor.

Hitting the on-line DTDs on every invokation of Saxon unnecessarily burdens the W3C Web site. I had already found guidance on how to use the Apache XML Catalog resolver to avoid that, but it wouldn’t work with the default XML catalog list provided by Ubuntu in /etc/xml/catalog for the XHTML DTDs.

After some investigation, it appeared that the use of a bogus URL as a SystemID in the intermediaries XHTML catalog files prevents the proper parsing of these catalogs, and thus make the local DTDs undiscoverable.

With the patch provided in my bug report, I can now happily use /etc/xml/catalog with saxon and never hit the network when transforming XHTML files:


java -cp /usr/share/java/xml-commons-resolver-1.1.jar:path-to-saxon8/saxon8.jar -Dxml.catalog.files=/etc/xml/catalog -Dxml.catalog.verbosity=1 net.sf.saxon.Transform -novw -r org.apache.xml.resolver.tools.CatalogResolver         -x org.apache.xml.resolver.tools.ResolvingXMLReader         -y org.apache.xml.resolver.tools.ResolvingXMLReader XMLFile XSLTFile

Validating XHTML Basic 1.1

Dom — Tue, 16 Jun 2009 16:03:23 +0000

As I was trying to validate a large number of XHTML MP 1.2 files (the ones in one of the OMA’s XHTML MP test suite – whose welcome page itself ironically is not well-formed), I realized that the tool I was using, based on the WDG HTML validator as packaged by Debian, was making network access requests when used on these XHTML MP 1.2 files. I then moved to use xmllint with the --valid option, but it had the same behavior.

As one of the W3C Systems team member, I’m acutely aware how bad is the practice of fetching DTDs over the network over and over again.

Furthermore, the OMA XHTML MP 1.2 DTDs are broken – they include non-UTF-8 characters in the comments of one of the modules (bug that I have reported a while ago but that still hasn’t been fixed apparently).

But given that XHTML MP 1.2 is mostly equivalent to XHTML Basic 1.1, I thought I would validate the said files against that DTD – but I wanted to make sure I wouldn’t hit the network when doing so.

Unfortunately, the XHTML Basic 1.1 DTD was not installed in my local XML catalog by default as part of the others DTD in the w3c-dtd-xhtml package – I’ve filed a bug report in the hope that it will be in the future, along with the XHMTL+RDFa DTD.

So I looked into adding the XHTML Basic 1.1 DTD to my local XML catalog, and marking it as an equivalent of the XHTML MP 1.2 DTD at the same time. Given that this wasn’t exactly straightforward, I thought I would document here what I did to set that up on my Ubuntu Jaunty install, in the event that someone else would need to do something simiar:

first, I added the following lines to my /etc/xml/catalog file:
I edited /etc/xml/w3c-dtd-xhtml.xml to add the following lines:
I created the directory /usr/share/xml/xhtml/schema/dtd/basic11/ and put the following files in it (available as a Zip file):
- the SGML Catalog definition of XHTML Basic 1.1 – since I’m now using xmllint rather than the WDG validator, I’m not sure if it works or is useful as is
- a modified XML Catalog file that points both the XHTML Basic 1.1 FPI (-//W3C//DTD XHTML Basic 1.1//EN) and the XHMTL MP 1.2 FPI (-//OMA//DTD XHTML Mobile 1.2//EN) to the XHTML Basic 1.1 DTD
- a corrected version of the flat DTD for XHTML Basic 1.1, that includes all the necessary modules as a single file – while it was based on an old version developed by the XHTML Working Group, I had to update it quite a bit to make it actually represent what the XHTML Basic 1.1 spec says
- I have also included other files that I had found in the similar catalog directory for XHTML Basic 1.0, but I think they’re only useful for SGML-based validation, rather than XML-based – they are also in the Zip file, but may not be useful
With these changes, I’m now able to validate my XHTML MP/Basic files without hitting the network. But the main lesson for me remains that it isn’t exactly trivial to add DTDs to a catalog when it isn’t done by people who actually know what they’re doing…

beta.w3.org is live!

Dom — Fri, 20 Mar 2009 16:31:33 +0000

The long-announced W3C site redesign is finally going live, in beta for the time being, at beta.w3.org.

Although I’m far from having been the lead in that project – nobody has even come closed to the amount of energy and willpower Ian has put into it -, I’m still quite proud of the areas where I have been able to contribute to, in particular the completely new information architecture, the focus on usability on user-centric navigation, as well as some participation in the software architecture and development that is used in the background of this redesign.

I’m hoping many will find the new site a vast improvement on the current site, and that we’ll also get plenty of contributions, in the form of comments, bug reports, and some of the texts that we still need to complete some of our new pages.

Synchronizing text and video

Dom — Fri, 13 Feb 2009 12:31:32 +0000

After having visited the land of transcription as my first stop in the world of Web video, the next logical step was to look into how this wonderful transcription of my video could be actually shown along with the video.

Transcriber, the tool I used to generate the captions of the video, saves the transcription into its own XML format:

ParisWeb 2007 - Les Bonnes Pratiques du Web Mobile" 
  air_date="2007-11-16">
Dominique Hazael-Massieux" 
  audio_filename="parisweb" version="5" version_date="090210" xml:lang="fr">
  
    Stéphane Deschamps" 
      check="no" type="male" dialect="native" accent="French" scope="local"/>
    
  
  
    
      
      Y'a quelque chose auquel on croit beaucoup à ParisWeb,
      
      c'est "les standards, c'est bon, mangez-en",
      
      c'est pour ça que cette association existe

It offers the possibility to export it in a variety of other formats (including HTML), but for sake of exploring one of the technologies in development in W3C for that precise use-case, Timed Text DFXP, I started to look into transforming their XML format into Timed Text.

Another motivation for that was that Subtitle Editor, the other tool I had looked at, is able to import and export timed text data; this also meant that very same tool would allow me to quickly visualize the subtitles superimposed to the video, one of the advantages that it had over Transcriber.

It turned out (unsurprisingly, I suppose) that the conversion between the two formats was really quite easy through an XSLT style sheet; the main structural difference between the two formats is that Transcriber notes break points as XML elements ( in the example above), while TimedText wraps the transcripted content into elements ( or

So, now that I had a Timed Text version of my transcription, how did that help me putting the transcripted video on the Web?

Looking quickly on the Web, it seems that some Video hosting services, including dotSub and dailymotion but not (I think) Youtube, allows publishers to upload subtitles with their videos; as I have verified since, dotSub even supports importing and exporting subtitles in TimedText format.

But I was curious to know how to include these subtitles in a self-hosted video situation; I had little hope to find subtitles support through the classical tag in HTML, but I was hoping that the new element in HTML 5 would help solve that problem.

Unfortunately, it doesn’t out of the box as of the draft dated of February 12 :

[…] authors are expected to provide alternative media streams and/or to embed accessibility aids (such as caption or subtitle tracks) into their media streams.

That certainly seemed extremely suboptimal to me – having to download a whole video to access its transcript doesn’t sound like a good use of anyone bandwidth. Discussions on fixing that current state of the HTML 5 spec have apparently started, and brought to my attention the work that my colleague Philippe had started to implement a JavaScript-based TimedText player for HTML 5.

This was exactly what I needed, and I thus started to play with that code to embed subtitles of my video in an HTML page.

And this is what got me started to look into why the new element in HTML 5 is actually a game changer, rather than just a nice wrapper around the existing functionalities in – which is what my next blog post will look into.

Exploring the world of Web video

Dom — Wed, 11 Feb 2009 14:33:20 +0000

A colleague of mine recently pointed me to Michael Wesch’s great and inspiring anthropological introduction to YouTube, which made me curious about the use of video as an expression mechanism on the Web.

Coupling this with my recent upgrade in the camcorder world to a fully digital device, and the early results of the Video in the Web activity W3C started a year ago, I had to start playing in this area to understand it better.

As a starting point, I thought that I would use the video of the presentation I made to ParisWeb back in 2007 on the Mobile Web Best Practices, also available un-flashed on ParisWeb servers – usefully made available in a by-nc-sa Creative Commons license.

One thing that I needed to take into account, but was also a driver for this exploratory work, is that we are about to adopt a W3C internal policy that we can only publish media on-line if we ensure a minimum level of accessibility – at this time, this minimum level requires providing a full transcript of any material.

This post serves as an introduction to my adventures in the hazardous world of Web videos, where you’ll find me finding my way:

in the world of transcription, and the tools available to that end on linux,
in the formats for publishing and associating the transcripts with the video,
the proposed HTMLMediaElement DOM Interface to make it possible to synchronize events with media playing, adding a pinch of JQuery, RDFa and Media Fragment to taste.

At the end of these stories, you will join me in rejoicing in front of a synchronized, close-captioned and annotated video and slides presentations viewer for your browser – if you browser lives sufficiently on the edge, that is (which I think at this time means specifically Firefox 3.1 beta), and if you’re patient enough to deal with video operations on a 85 MB video. And if you speak or read French.

And if you’re not patient enough to go past these obstacles, I have prepared a screencast of the system in action:

Transcript:

[the screen shows a Web page in a browser, split in 4 zones]

This is a screencast of a presentation viewer written in HTML and Javascript.

You can see here [on the top left corner] the area where the video will appear, here [on the top right corner] the slides that will accompany the video presentation, and there [on the bottom left corner] a table of contents.

If I start the video here [clicking on the play control of the video], you can see the closed captions appearing below the video.

And then I can navigate in the video and the presentation using the table of content.

And you can see how the video and the slides get updated live, and I can even have side notes appearing on the side [bottom right corner] of the screen.

(also available as Ogg/Theora video with a Timed Text transcript.)

Microblogging

Dom — Tue, 20 Jan 2009 03:52:44 +0000

In case it wasn’t clear from the past three entries posted here, I have started to microblog on Identi.ca – the open version of Twitter. I’m still trying to figure out whether I should have my posts also mirrored on twitter, where most of other microbloggers I know are gathered – oh for openmicroblogging in Twitter!

I had started aggregating my microblogs on this blog through feedwordpress, but found the results too noisy – in particular since this blog is syndicated on the W3C Team blogs’ galaxy where the microblogs would end up filling all the entries. I’m still looking into finding a good way to show my microblogs on this site, though; for the time being, they are a link away.

Note that Twitter doesn’t think my name can contain more than 20 characters – a curious echo to a similar problem I experienced with Air France.

We’ll see how that microblogging experiment works out; I had already been using Twitter from time to time on the mobiweb account without much regularity, but from my short experimentation, I think a personal microblog has more chances to get used.

JQuery, yummy

Dom — Tue, 13 Jan 2009 10:45:07 +0000

I have resisted for a long time to use Javascript in my Web projects, for two main reasons:

it is relatively painful to write standard-compliant (read DOM-compliant) javascript;
I’ve brainwashed myself to associate Javascript with accessibility problems.

I keep fighting myself on that second reason – the movement toward Graceful Degradation & Progressive Enhancement certainly helps me making peace with myself on that front. I guess some of my early Web experience where I ended up coding an entire Web site mostly in Javascript gnaws at my standardista conscience…

In terms of the pain in writing DOM-based scripts, and since I have re-started writing a bit of Javascript in the past two years, I must say that my recent experience with JQuery has been really good, and makes go away pretty much most of the pain of finding elements, looping through them, creating nodes, etc. It does bring a bit of syntactic awkwardness with all these lambda functions embedded everywhere, but overall, it makes coding in Javascript a pleasure rather than a dread!

DTD comparison

Dom — Wed, 12 Sep 2007 11:57:08 +0000

As a follow-up on my toying with DTDs, I added a new Python script to my toolbox this morning: dtd-compare.py allows to compare the vocabularies defined in several DTDs to see which elements and attributes are present or absent among them.

For instance, running python dtd-compare.py http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd http://www.openmobilealliance.org/tech/DTD/xhtml-mobile10.dtd http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd has allowed me to build a comparison of the various mobile XHTML flavors with the content of XHTML 1.0 Strict.

I haven’t included XHTML MP 1.1 and XHTML MP 1.2 in that comparison chart since the officlal DTDs seems to have syntax errors, reported by the script as follows:

ERROR: character set conversion problem: 'utf8' codec can't decode byte 0xa9 in position 260: unexpected code byte at http://www.openmobilealliance.org/tech/DTD/xhtml-mobile11.dtd:1:0
ERROR: character set conversion problem: 'utf8' codec can't decode byte 0x92 in position 715: unexpected code byte at http://www.openmobilealliance.org/tech/DTD/xhtmlmp12-form-1.mod:1:0

Generating HTML documentation from DTD

Dom — Tue, 31 Jul 2007 13:58:21 +0000

I consider myself fairly fluent in XML technologies, but there is at least one technology that I have never bothered to fully learn, nor that I am planning to ever fully learn, and this would be XML DTDs.

Some people would like DTDs to disappear completely off the face of XML, and while I wouldn’t disagree with them, I still have to live in a world where some markup languages are formalized using DTDs, and even more importantly, where the greatest part of the developed markup language productions is checked using DTD (typically with the W3C Markup Validator).

So, instead of learning the arcane syntax of DTDs, I wrote this dtd-doc.py Python script that relies on an existing Python library that parses DTD (and thus on having someone who actually read and understood the DTD specification). It takes as parameter a DTD URI, and outputs a couple of HTML tables describing which elements and attributes are defined in the given DTD.

You can see the result of the script in the just-released XHTML Basic 1.1 reference.

The script is not anywhere the nicest code I’ve ever written, and it probably actually tops the list of the ugliest Python I’ve ever written; but then, it’s dealing with DTDs, so that seems only fair!

A bright eclipse

Dom — Fri, 06 Jul 2007 07:05:19 +0000

Most of the Web development I work on is, for good or for worse, using PHP – my natural preference would go to coding in Python, but PHP is what was and is available on the W3C servers, and I’ve become much more fluent in it than in any other programming language.

One of the most annoying things to me with PHP (at least with PHP4, I haven’t really worked with PHP5 yet) is how clumsy the object model is and how lame the API appears: after more than 7 years of continuous development in PHP, I still have difficulties remembering the name of very classical functions, or when I do, I can’t remember the order of the arguments – the functions dedicated to arrays are a typical example of these, probably because they didn’t have a well-known C ancestor, and thus were likely designed on the fly by the early PHP creators.

Also, I have only recently started to use phpDocumentor, a rather powerful package that allows to create nice documentation for PHP projects, to the (unavoidable) cost of following the classical JavaDoc documentation style. But once this documentation gets created, I felt really disappointed that the effort put in it couldn’t be used directly while developing without having to navigate through it in my browser.

The obvious answer to these problems is to use an IDE, but the past few times I had been looking, I didn’t find anything very exciting for PHP development on linux, and thus have been using Emacs with mod_php for many years.

But my last investigation of the topic, motivated by a few attempts to code in Java for the mobileOK checker new generation, was the good one: the oh-so well-known Eclipse IDE has a “PHP perspective” (in Eclipse jargon, a module to handle PHP development) that just reached version 1.0: PDT, standing for PHP Development Tools.

I first tried to get it to run on the version of Eclipse provided with Ubuntu, but quickly ran into dependencies hell – but given that this attempt just followed the release of a new version of both Eclipse and PDT, I can’t say, retrospectively that I am too surprised. So I eventually opted for the all in one package made available, and have been happily experimenting with it for the past few days.

My general impression is extremely good; I don’t have to think anymore to remember my function names or my classes definitions, syntax errors are highlighted in a much more reliable fashion than they ever were in Emacs, and the tools to navigate through the code or create documentation are really practical and useful.

I still have to figure how to get better keyboard navigation – I still have to use the mouse to do e.g. CVS operations, which could be a back-to-zero problem shouldn’t I find the proper way to configure this. The thing is, there is one commonality between Eclipse and Emacs, they are full-blown operating systems in the guide of editors or IDE…

Making this blog mobile friendly

Dom — Wed, 20 Sep 2006 09:08:51 +0000

As I quickly noted when I got my Treo 650 PDA, this very blog didn’t look quite good when used on the Web browser included with it (Blazer v4).

Eigth months later, and with the Mobile Web Best Practices now in implementation feedback phase, I thought it was time that I applied the very principles I had contributed to develop to this blog (powered by Wordpress).

I had already done part of this “mobilizing” game for the Mobile Web Initiative home page, which is powered by a different blog engine (b2evolution, on which I plan to write soon), so this wasn’t exactly an unchartered territory for me; but here comes a summary of the main things I had to tweak to make it work (as confirmed by the Best Practices checker, but even more so by real usage on my Treo).

My main goal was to make this content accessible on mobile devices, rather than providing the best possible user experience on each mobile device, so I chose to target what the Best Practices call the default delivery context, in other words, a well-defined set of limitations one should take into account when designing for mobile devices in general rather than adapting the content for each and every device.

First thing I did was to seek compliance with the CONTENT_FORMAT_SUPPORT of the Best Practices, which means serving this blog as XHTML Basic, served as application/xhtml+xml; I have simply re-applied the technique I’ve written up a few weeks ago to permit serving my blog as XHTML Basic to all the clients that say they prefer application/xhtml+xml to text/html, with a workaround for Internet Explorer ambiguous behavior; given that the technique was already developed for PHP, this was mostly a copy and paste exercice.

Mobile Web Best Practices checker

Dom — Thu, 29 Jun 2006 12:50:05 +0000

As announced in the WWW2006 conference and as part of the Press Release accompanying the publication of the Mobile Web Best Practices as a Candidate Recommendation, work has started on the development of an open-source Best Practices checker.

It is still at alpha release stage and hasn’t been properly reviewed by the Mobile Web Best Practices Working Group; meanwhile, developing it has been a lot of fun!

First, for once, I was able to code in Python; even though my skills in Python are still rough and my ratio PHP/Python line codes must be around 1/40, I would give all my PHP code for keeping Python code only. For mostly historical and logistical reasons, most of my day to day coding has been (and likely will continue to be) made in PHP, but PHP really looks like an ugly pig compared to the lightness and flexibility of Python. Really.

Secundly, I was able to work with unit-tests from the very beginning; I’m usually doing a lot of database-bound applications, which I find really cumbersome to unit-test; in this case, given that the code targets HTTP delivered content, designing and setting up unit tests was extremely easy, and proved similarly valuable: it’s hard to over-estimate the confidence you get in your code when you know it passes a series of well-defined tests.

Thirdly, while some of the code is really mobile-specific, a lot of it could be used a basis for a more general Web Best practices checker: it can make interesting remarks on form controls (e.g., check whether each control has a corresponding label), on images and their dimensions (e.g., whether the dimensions of the images are defined in the markup and whether they match the dimensions of the image itself), on auto-refreshing and markup-redirect pages, on the proper usage of HTML headings, on the usage of tables layout, etc. Codifying some of these well-known Web design issues in actual tests and code was sometimes challenging, but mostly very rewarding.

Finally, I got to use a nice set of very Webby technologies:

first of all, the checker uses thoroughly caching for its HTTP requests, thanks to httplib2 which does most of the dirty work;
given that the checker also does some markup validation, it relies on xmlproc catalog’s handling capabilities to skip any HTTP activity for known DTDs;
a great chunk of the analysis made rely on SAX parsing; it was my first opportunity to use SAX in some real coding, and I have to say I found it quite pleasant to use
some of the devil-lies-in-the-details tests for encoding and MIME-types needed careful comparison between the various specifications involved (HTML, HTTP, MIME-Types, CSS among others)
I got a fairly nice logic/presentation separation through the use of templates; for (potential) compatibility with the Markup Validator, I used a Python implementation of Perl’s HTML::Template language

There is still quite a lot of work to be done to make it more robust and more complete; in particular, I need to analyse CSS style sheets for testing some of the best practices: I was thrilled when I discovered cssutils – CSS Cascading Style Sheets library for Python, until I realized it doesn’t implement the most important CSS DOM interface I needed. I’m left with the option of either implementing it myself, or looking at using some other non-Python library (e.g. libcroco). I’m also hoping to use Mark Nottingham’s cacheability engine to implement the test for the Best Practice on caching, if I can get it to play well with the other modules.

But I’m already quite satisfied with all I learnt during this first phase, and the feedback I’ve been able to provide the Working Group based on this coding (which reminds me that I still have some rather thorny implementation feedback to send!).

The code is already available and there are some velleity of an installation document if anybody wants to play with it; if you want to contribute to the project, I very much welcome so; just drop me an email at <dom@w3.org> to get in touch!

Small SURBL Python library

Dom — Tue, 18 Apr 2006 11:59:25 +0000

The spammers have striken again, and we received reports that one of our extremely useful public service was used to work around URL matching techniques for spammers. In other words, a spammer who would have been identified (in email messages, blog comments) as using http://example.net/ as a URI in his spam could workaround it by putting a link to http://our-useful-service.example.org?uri=http://example.net/ instead, and given that the said service more or less entirely preserves the content as is, this allowed indeed to put a link to the incriminated content.

The reporter of this abuse of service had the good idea to mention an existing technical solution to this type of problem: SURBL is a registry of registered domain names that have been reported as used by spammers. Although I’m not a big fan of this type of registries (they really seem the lowest type of trust network one can imagine, too easily abused), faced with the alternative of shutting down the service entirely or reducing the possibility of abusing it, I took the second option.

As the said service (that I’m not mentioning explicitely in case it would draw more attention that it needs at this point) is written in Python, I’ve been looking for a Python implementation of the SURBL mechanism; unfortunately, I haven’t been able to found one and so had to write my own implementation, which seems to work well (units tests also helped) and now supports the alluded on-line service.

SURBL uses DNS queries as a way to query their registry: you ask whether spam.example.multi.surbl.org exists; if it does, then spam.example is part of the blacklist, otherwise it isn’t. In terms of implementation, the only (rather small) difficulty is to identify the relevant part of the URI you want to check, namely the registered name used in the authority component of the URI. This implies removing the possible port and user information parts in the authority component, but also the possible sub-domains of a registered domain; this would be entirely trivial if one didn’t have to take into accounts delegated second-top-level domain names (e.g. as co.uk).

SURBL’s architecture is a rather smart way to re-use the existing caching/query infrastructure deployed for DNS (e.g. I just had to import DNS Python to query their blacklist). I suspect that the software infrastructure behind DNS implements caching more widely than most implementations of HTTP do, and thus would induce a smaller load on their servers – although I haven’t quite checked it. Of course, the DNS system is particularly well fitting to this, given that the queried items follow (by definition) the naming rules of DNS. Also, I guess that the primary usage of the system (mail filtering) made DNS a pre-requisite, while access to an HTTP client may be less obvious. But I wonder if there would be any compelling reasons to make this also available as an HTTP service?

Doing HTTP caching in PHP

Dom — Fri, 10 Mar 2006 14:45:27 +0000

Since the Mobile Web Best Practices highlights that caching is a particularly important feature when browing the Web on a mobile device, I just wrote a new associated technique on how to do proper caching when using PHP.

While Mark Nottingham’s excellent tutorial on the topic covers most of it already, the technique provides some additional code example, as well as some illustration as how to use it with MySQL.

Nothing ground breaking, but I’ve been using this code in most of my PHP applications over the past years, and it certainly gives a nice and warm feeling of being a good HTTP citizen when you pass the Cacheability validation.

(As we’re trying our best to keep the Mobile Web Initiative home page in conformance with the best practices, this code has just found a new usage in a mobile context…)