sjh - mountain biking running linux vegan geek spice - mtb / vegan / running / linux / canberra / cycling / etc

Steven Hanley hackergotchi picture Steven
Hanley
About

email: sjh@svana.org

web: https://svana.org/sjh
twitter: https://twitter.com/sjhmtb
instagram: https://instagram.com/sjhmtb

Other online diaries:

Aaron Broughton,
Andrew Pollock,
Anthony Towns,
Chris Yeoh,
Martijn van Oosterhout,
Michael Davies,
Michael Still,
Tony Breeds,

Links:

Linux Weekly News,
XKCD,
Girl Genius,
Planet Linux Australia,
Bilbys,
CORC,

Canberra Weather: forecast, radar.

Subscribe: rss, rss2.0, atom

←December→
Mon Tue Wed Thu Fri Sat Sun
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

←2004→
Months
Jan Feb Mar
Apr May Jun
Jul Aug Sep
Oct Nov Dec

Categories:

Archive by month:

Wed, 22 Dec 2004

Why are you not a fish hatchery worker? - 21:29
As mentioned, Mikal is evil, he pointed out how funny and clever this guy (Rory Blyth) is. Yet another thing to use up some time, and damn Mikal was right, the guy is clever and funny. Anyone who says something like

It was a day like any other in 1987.

Unless you choose to differentiate it by the rows of luncheon tables covered with newspaper, plastic, large salmon, and cutting implements.

Aside from that, it was very normal.

The reason I said that "It was a day like any other" is that there's a good chance that you work at a fish hatchery or a morgue. In either case, you should be able to relate easily to the events of this story. On the outside chance that you aren't a fish hatchery worker or an embalmer of the dead, then things might seem a little strange, but let's be honest: It's your fault for choosing a profession so strange that it doesn't involve regular contact with dead fish and flesh-cutting tools.
(source)

deserves to be read, I just have to remember to go read more of the stuff this guy has written now.

[/amusing] link

ACAP for data access appears difficult - 20:50
In response to my post suggesting address book data be placed in an IMAP folder for easy access from any IMAP client. Brad pointed out the ACAP effort. Admittedly I noticed this rfc on the imap rfcs page when I glanced at it earlier, I did however ignore it as it looked complex. Now looking closer I think I was right it is complex.

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)

[/comp/email] link

RSS bandwidth usage - 19:10
Mikal is an evil man, writing a blog entry I just had to respond to (with some research and fact checking) and thus using up time... (or I suppose I could simply stop this online diary thing, after all Andrew is of the opinion (possibly accurate) that I am addicted)

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.

[/comp/blosxom] link

Address book storage in an IMAP folder - 17:52
Talking with Bill Clarke last night at work about IMAP issues (I was doing work on more features and stuff for our new email system at work) and he made what I thought was a pretty bloody good suggestion. One of the problems with IMAP storage of email, is though you can access your email from anywhere, you do not have an associated address book accessible from anywhere in all email clients that support IMAP.

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.

[/comp/email] link

home, email, rss, rss2.0, atom