Applications that use local RDF files to store data have a significant
potential point of failure. I have come a cropper on a few occasions
with RDF files getting 'corrupted' and trying to repair them by hand is
well nigh impossible.
For my own XUL/RDF applications it struck me that a rolling 'backup'
would be a neat idea - when an RDF file was successfully opened/parsed a
zipped backup would be created. The backups could be rotated and a user
could also undertake a manual backup of the critical data when every
he/she wanted. Since these files can be quite large compressing would
be essential.
The problem I discover is that XPCOM has an interface for reading zip
files (an essential part of supporting http/1.1) but I cannot find a
means of writing zip files.
The combination of XUL/RDF/XPCOM/Javascript is immensly powerful for
developing cross platform applications but it seems to suffer somewhat
from being too browser centric.
To be really useful, as a development platform, xpcom's nsIZipReader
should have a nsIZipWriter counterpart. Clearly, adding this type of
component, as part of the standard browser release, would increase the
footprint and would not be desirable but it *should*, IMHO, be a
standard xpcom component, available to application developers to
incorporate into their application.
The ultimate question is, therefore, are there developers working on
standard (open-source) xpcom components that make the XPCOM platform
more comprehensive? If I was to write an implementation of
"nsIZipWriter", would there be demand and testing/development support
out there?
XUL/RDF/XPCOM/Javascript could liberate developers from the clutches of
MS-COM and fulfill the cross-platform potential only dreamt of for
client side JAVA. To do this it needs to be more comprehensive than a
browser application.
Reactions?
Geraint
