Wednesday, March 22, 2006

Ok, so I finally found a good Java iCal parser and got it working on most of the .ics files I have:iCal4J at sourceforge

It does have problems with CHARSET properties, because it doesn't know them.Which is actually in line with RFC2445... however, they do exist.To work around this you have to write your own content handler, but it works.

More importantly - and annoyingly - I just started working with an iCal parser that believes they are not.So everything abvoe 127 terminates e.g. a description or summary.German invitations/events tend to have äöüß in them (especially the ß in the location component), yet they don't parse correctly...

Monday, March 20, 2006

There are many problems as the industry tried to establish a calendaring/scheduling standard.Less technical.

Technially speaking everything seems to be solved (for me).

The problem is rather – I think – in the plethora of ways people (in real life) work with calendars, and how their understanding of scheduling is.

One of the problems is e.g. with the understanding of recurring events (not covered today). The other is with time zones, and how people ignore them.

Yes - time zones.We thought, that the problems of specifying a local time were actually solved with the invention of time zones.Still, what do you do (programmatically, not as a human being), when you receive an calendar event without any time zone information.Not even a UTC marker (as in the generally accepted ISO8601 standard).Which time zone does this event fall into?In real life you say “The time zone of the organizer or the person you received the invitation from (i.e. the sender)”, and you are usually able to resolve this, because in real life you at least have a hint what their time zone might be.As a program, how do you tell – in the absence of any TZ information?Which TZ do you pick?Is it fair to assume that then sender has the same TZ as you (the receiver) has?

Or should you just shoot programmers who do not include TZ information in their events?Or is it the standard ? ISO8601 allows for empty TZ information and simply declares those as being "local". Local to what?

Tuesday, March 14, 2006

Isn't the problem of music download rather in the old business model of the recording industry?

Their model was built on charging for the media, i.e. the carrier of the (copyright protected) song/music. If you bought the same song a second time (e.g. on a sampler LP, or you broke the record and had to buy it again), did they step up to you and said, “No wait, you already paid for that; we'll just take some cent for the vinyl this time”?

Well, they didn't come knocking on my door.

Quite the contrary, by changing from vinyl to CDs, they built an entire industry around charging a second time for the very same content.

Again: The whole business model was built around charging for the physical carrier.

But know, since they lost control over the distribution channel, it's suddenly all about the (protected) rights of the artist and their royalties. (... and they do have a right to receive royalties).In Austria and Germany (and probably some other countries as well), there was (and still is) a surcharge on each and every blank (!) MC, CD, DVD, ... just because you might copy something on it, that is royalty afflicted. Doesn't that actually imply that I can freely download (or copy) from whatever source, because I already paid some royalty? Or can I then get a refund for the surcharge on the blank CD...

Was there any limitation on a vinyl that kept me from playing “my” (in a DRM sense) record on my friends record player? No.The only limitation was that I didn't give away my records, I couldn't “share” them. I could only lend them to a friend, and I wanted to get them back – preferably without a scratch.And, because everything was analog, a copy had less quality than the original.

And this model of sharing formed the base for the average price of a song or LP.Meaning: the recording industry and the artists knew that some people gave away their LPs, and their friends copied them to MCs... This limited sharing/copying was already calculated into the price of every LP/CD/...

Divide the price of a LP/CD - about 15 US$ for a new release - by the number of tracks it features, say 12.What do you get (apart from 1.25$) ? The price per track/song.

To me, this is the price per song including the rights to give a copy to friends and/or play it on their player. Because the model is still the same as in the days of vinyl, where it was OK to do so.

So, for a “this-is-the-song-you-may-only-play-it-on-your-MP3/CD-player-and-not-give-it-away-to-friends”-copy of a song, you should pay less, because you are limited in how you use it.

The difference between the average street price per song on a CD (as given above) and the personal-use-only-price has to be the value of sharing that song.

Either that value is small, then what's the industry complaining about?Or the value is large, then personal-use-no-copy-option-included tracks have to become cheaper... substantially cheaper.

You could also call this piece: "Don't re-invent mozdev!"...and it generally applies to every SW "issue".

Before sitting down and starting a project/hack, check if it does not yet exist.

This very instance of this insight has its origin in me no longer wanting to manually switch the FireFox proxy, whenever I switched from my home directy internet connectivity (wifi+dsl) to the company VPN, where I have to use a proxy.

Actually I wanted to do some little hack to automatically determine, if the VPN was on, and then magically using the company proxy...

...but this here is quite sufficient: the ProxyButton extension.Gives you a little button on the toolbar to switch from direct to proxy...