News and views from a software developer's perspective
Thursday, April 04, 2002Is your e-mail watching you?. Marketers may be tracking your moves online through e-mail messages that share the look and feel of Web pages--and often without regard for safeguards that protect consumer privacy. [CNET News.com]
Yes, email marketing companies use cookies and web bugs to track your actions on the email they send you. We've known this for a few years. Why haven't the companies that make email client software figured this out? Here's a hint: if you see a tag like this
<img src="http://spamsource.com/image.gif?id=873905">
guess what? That's a web bug. Else why would a GIF image need a query string (the part of the URL the follows the question mark).
Here's an idea. How about if we use HTML mail in simple ways, like using bold and italic for emphasis, and bulleted lists for organization. Let's drop the tables, forms, images with HTTP URLs, etc.
News.Com: Microsoft preps content locks for devices. 
[Scripting News]
This amazes me. The content owners whine and complain about piracy on the Internet, yet they clearly appear to be overly greedy. One of the reasons they won't allow content to be moved to portable digital devices is because they don't have a system clock, which they require so that they can "expire" the content after a certain time, and because they don't have the persistent storage to count how many times a song has been played, again, so that they can expire the song after a certain number of plays. So, in the old world of CDs, you could buy a song and listen to it until your CD wore out. In the new world of digital content, you have many new restrictions that are put there by greedy companies that want to get even more money from you.
So, copy protection isn't just about stopping piracy, it's about new experiments in ways to extract more money from consumers.
In addition to your cable TV bill, your cell phone bill, and your ISP bill, get ready to pay $25 per month to listen to music.
Slashdot: Seeking Arguments Against the CBDTPA How about this as an argument against the CBDTPA: The law would not guarantee that the content owners would make their content available in digital form. If they don't think the government-mandated copy protection technologies are sufficient, then they just refuse to release their content onto the Internet. A slight variation on this theme: they release their content, but it is so tightly controlled or so expensive that consumers don't buy it.
I'm thinking of drafting an Email Customer's Bill of Rights. Some features that I think ISPs should provide to their email accounts:
- The ISP should add header fields that contain the SMTP envelope; specifically, the envelope sender, the envelope recipient, and the date and time the message was received. Surprisingly, many ISPs don't allow you to discover the envelope sender or recipient.
The SMTP envelope contains important information that is essential for managing one's email effectively. Here's a perfect example: you subscribe to a mailing list, but there is no way to automatically and reliably move all mail from that mailing list into a folder dedicated to that list. You could filter based on the envelope sender (the email address of the mailing list maintainer), but if your ISP doesn't provide that information to you, you're screwed. You have to do the best you can, and frequently you have to manually move messages into that folder.
more to come...
This document describes a format for storing outlines in XML 1.0 called Outline Processor Markup Language or OPML
I wish OPML could be redesigned. I like the idea of using outliners to organize thoughts, manage "To Do" lists, and so forth, and I like the idea of a standard XML format for outlines. However, I have some problems with OPML's current form. The biggest problem I see, is that the text of the outline is contained as the text of an attribute(!) This means there is no sensible way to display an outline using CSS; you must use XSL. It also means that mark-up in the text of an outline is pretty much meaningless. (Maybe that is why the designers chose this design. Who knows?) Third, I suspect that putting the outline text in an attribute makes it much harder use off-the-shelf XML editors to edit outlines. For example, if I use emacs PSGML mode, then I am prompted for the text of a attribute in the minibuffer, which is not where I want to edit large amounts of text.
If I had been designing OPML, it never would have occured to me to put the outline text in an attribute. I understand XML and SGML-like mark-up languages to consist of text + mark-up. The text is fundamental. The mark-up is secondary. In particular, the mark-up is placed within the text. OPML gets this backwards by putting the text within the mark-up.
What Are Web Services?
It seems that almost anyone you talk to has a different idea about web services. Here's my take on what web services are:
We begin with the current state of the web, where there are numerous web applications -- applications that have a web browser interface. Then, we find that web browser interfaces are not state-of-the-art user interfaces. In fact, we begin to think that we have taken a step or two backward in user interface design. Next, we find that web applications are great for user/computer interaction, but are not so good for computer/computer interaction. HTML is okay for displaying web pages in a browser, but terrible for computer to computer communication. Computers are just too precise -- too unforgiving -- and communication between computers must also be precise.
Web services, then, is just an evolutionary step beyond our current day web. There are two problems we solve: First, we replace HTML with XML to provide the precision we need for computers to talk to computers. Second, we allow for richer user interfaces by moving beyond the browser. This latter point is not obvious. Indeed, the reason browser-based interfaces became so popular, is because the web browser is a universal client. In short, when you have a browser-based application, deployment is a non-issue. However, the web browser is very much a thin client. Even with client-side scripting (JavaScript), the web browser is still somewhat limited. In particular, browsers are not good at aggregating or combining data. I don't think that anyone will create a client application solely to build a better interface than what you can get in a web browser. However, client applications that already have a reason to exist can be enhanced by communicating with other computers that offer web services. Think of an email client application, for example, which can be modified to use various web services as part of a collaborative tool.
Some people equate web services with software the runs on a server computer and is paid for with a subscription. I think that such server-based software is a different concept from web services. And unfortunately, equating the two causes a lot of confusion. The reason I think such services should not be called web services is because they are most likely based on proprietary client/server interfaces. True web services, on the other hand, have interfaces based on XML and other standard protocols like SMTP or HTTP. The real test of whether a service can be called a web service ought to be this: can you have multiple client applications from different vendors. Tightly coupled client/server software from a single vendor does not fit that definition.