Other online diaries:
Wed, 22 Dec 2004
Why are you not a fish hatchery worker? - 21:29
It was a day like any other in 1987.
deserves to be read, I just have to remember to go read more of the stuff this guy has written now.
ACAP for data access appears difficult - 20:50
About two years ago when a vulnerability in the default implementation of ASN.1 was discovered, almost every appliance or library using it was found to be vulnerable. Although many important protocols (SSL, LDAP, SNMP, etc) use ASN.1 no one had bothered reimplementing it due to the huge size and complexity of the standard. The ACAP people say their protocol is supposed to fill "niche somewhere between a full-blown directory service, a file system, and specialised single-service protocol support".
I still think it is too complex, if you think about basic rss and how much it has taken off, there is no real formal protocol or XML dtd, or anything, rss is simple to implement on both client and server end and it tends to work using standard libraries and tools. I did a CPAN search for ACAP, there was nothing remotely usable available in CPAN to speak ACAP, nor was there a Debian library (apt-cache search acap) or something to make it easier. If you have an IMAP client already however, there are a bunch of vCard libraries in CPAN and Debian, the same applies for the other stuff (email with vCard mime attachments) in Bill's suggestion for an address book in IMAP.
The other thing is I have never seen any mention of ACAP support in a feature list for an email client. (though I have not looked explicitly for this)
RSS bandwidth usage - 19:10
Anyway Mikal wondered why the rss standard could not simply add a field suggesting blog update frequency to rss feeds. Ignoring for a moment that rss is a bit of a mess and not really standardised (with rfcs and other such stuff), this suggestion requires clients to implement it properly, and would require all the feed formats (rss 0.9, rss 1, rss 2, atom, etc) to have this sort of functionality. I generally do not trust clients to implement standards properly, and these are not even real standards.
I mentioned to Mikal a recent post I had seen somewhere like BoingBoing about how someone had implemented a nice way to cut off people gobbling too much bandwidth at the server side. A bit of a google search found the entry I recalled seeing. This keeps track of UserAgent/ip, and takes note of feeders that abuse the system (constantly re fetching data they already have, etc), to do this one would need to keep track of this data in some manner which is non trivial and can use memory or disk. Also of course people behind a corporate proxy or firewall and those on roaming proxy's such as AOL subscribers may have problems with this implementation. The implementation discussed only throttles the feeders that abuse (consume more bandwidth than they should) so people using better clients will not be hit.
I have to say I do not particularly like either of the above implementation suggestions, Mikal's suggestion due to the need for compliant implementations and the fact I don't think predicting your update frequency is worth the effort. The server side enforced limiting due to added load and complexity on the server side and due to the limitations of the method. There really is no way to solve this that I can think of that is likely to catch on. What really needs to happen is rsync in the http protocol (rproxy) needs to be adopted in http servers and http clients.
Address book storage in an IMAP folder - 17:52
Bill's suggestion though simple and not some sort of IMAP extension or anything, to me appears elegant and useful. Store address books in a folder in your IMAP mail storage area. I thought, that sounds neat, use some common format such as vcard attachments to emails. So the folder, could be called anything and store an email per vcard file. The email client could be told to use the IMAP folder named "whatever" to get its address book information. Now all we need is someone to write a thunderbird extension and a squirrelmail extension to do this and we will be set.
I did look around google a bit and glance through the IMAP rfcs and could not see that anyone had done anything similar yet, of course I may have missed it. David Gibson has talked about plans to make a better mail retrieval protocol than IMAP from time to time, to get around problems such as the need for tools like offlineimap (and may I note, how cool is it that this is hosted on gopher). David may have thought of some way to add useful information to his protocol, however nothing is implemented yet so who knows.