dready blog v2.0

Thanks to Louis Gray’s Tip #5, I’ve installed Glenn Saven’s FriendFeed Comments WordPress Plugin bringing FriendFeed comments into the blog entries.

In a world of increasing openness and user-centric -ness (user-centric identity, increasing user-choice, user-controlled data), how do you convince enterprises to give up the data that they guard so dearly? One way to put it may be “it’s happening whether you like it or not, so you might as well go with the flow”. While companies can certainly go with the flow, more forward-thinking corporations may decide to do it more pro-actively, rather than being forced to react.

There were some talks about how VRM relates to DataPortability on the DataPortability-Public mailing list. In particular, this excerpt of a blog post from Adriana Lukas sums up the “What’s in it for business” aspect very well:

What’s in it for businesses?

We live in an increasingly decentralized world with more customer choice, yet vendors continue to fiercely collect and control customer data and exploit the opportunities therein. The ultimate goal of VRM is better relationships between customers and vendors, by considering and constructing tools that put the customer in control of their data and ultimately their relationships with other individuals, companies and institutions.

Benefits of ‘letting go’ of customer data:

• Customers share the burden of storing and protecting the data - eases compliance, privacy & security concerns
• Increased access to information about customers - direct benefits to the customer to share more data rather than less.
• New services from previously unavailable access to customer data

The first bullet is a good point that I had never thought about, and is a very practical benefit. The second point is a classic example of “less-is-more”; maintain less control, and gain more in return. The third point being direct consequence of the second.

When will we see the first product that presents a holistic solution with tangible benefits of VRM to companies, as well as integration with / transition from their existing CRM systems?

I monitor a few keywords on Twitter, and get instant notification on Jabber whenever someone mentions any of them. “OpenID” is one of those. Today, I got one notification which caught my attention, not just because it is in Chinese, but that I think it’s an important point:

jchristabelle: OpenID真的很難記，我又忘了我的。

which translates to:

OpenID is really hard to remember, I forgot mine again.

I have shared that sentiment before, when I tried to login to my Plaxo account and couldn’t for the life of me remember which one it was that I first used to associate my account. Granted that, in my case, I have many OpenID URIs because I’ve been so involved in the implementation. However, it is true that the OP:RP ratio is still too high (counting Blogger as a single RP rather than thousands of OpenID-ready spam blogs.)

I think it is inevitable that in future most users will have at least a handful of OpenID URIs. One can easily imagine getting one from each webmail/IM provider, personal i-name or domain name, social networks, etc. It may just be one of those annoyances we have to live with. Or maybe users will just remember the brands that stick, and click on the “Sign in with my Yahoo! ID” button instead.

I don’t have a solution here, just relaying the message.

p.s. Incidentally, geeks are of course still able to use URIs within their control (personal domain) to delegate to another OP (e.g. Yahoo) and switch OP at anytime while keeping the original URIs. For example, here’s what I use.

If you observe memcached exhibiting strange behavior while running under Solaris, you should try upgrading to the latest version of libevent.

I experienced a problem while testing my application on the excellent Joyent Facebook Accelerator, which runs Solaris Nevada snv_67 X86, has memcached 1.2.2 with libevent 1.3b2 installed by default.

My memcached usage is pretty low and I refresh the cache often to keep it from going stale, but somehow I still get lots of cache misses. By elimination, I ruled out the possibility of faults on the python memcache module, or memcached version (tried the latest 1.2.4 compiled against the libevent-1.3b2 and it still had the same problem.) When I connected my app to the memcached instance running on my FreeBSD box, though, the problem doesn’t exist.

Eventually, it turns out that memcached disconnects the client and all I got from the python memcache module was:

  File "/opt/local/lib/python2.5/site-packages/memcache.py", line 846, in recv
    'read returned 0 length bytes' % ( len(buf), foo ))

Well, that’s another bug. The above foo should really be rlen, but fixing that only proved that memcached always disconnects the client after sending 66887 bytes in response to a get.

After some poking around (by inserting prints and running memcached in foreground mode), it was apparent to me that memcached was getting an error from libevent, so I upgraded libevent and problem was solved.

Hope this helps anyone who may run into the same problem (as I couldn’t find any clue in the googs.)

Actually they do! I couldn’t resist but to click on the following when it showed up on my Gmail interface (even though I have heard of Woot before):

This goes to show that when it comes to ads, creativity pays off.

We launched another round of 6 languages in .BIZ on January 16th, 2008: Finnish, Hungarian, Latvian, Lithuanian, Polish and Portuguese (press release).

While NeuStar already has many Latin-based IDN languages in its portfolio, one may wonder why we would bother making the Venn diagram so complicated. Just define a Latin script-based table and be done with it! Well, since we tend to take a more conservative approach with IDN, it is safer to have each language table contain only the characters used by that language proper and nothing else¹. After all, we’re here to provide value and not to make a quick buck (at least that’s how I see it.)

¹ Language is constantly evolving. Often, it is not easy trying to determine if a character used in borrowed words is well-assimilated in the culture to be considered part of the language. There are no clear rules, do we follow the guidelines from the trademark offices’ of the countries in which the language is used? Or do we follow the ccTLD registry (if we do, does it make sense for a gTLD?) Or language institutions? Thankfully, there are many great resources to draw from.

I don’t have time to blog, really, but this is just too scary a thought. From this Techcrunch post:

A pact between the French Government, French ISP’s and the local music and film industry will see French users who download material from P2P networks losing their internet access.

French internet users will face a three strikes and you’re out policy, according to the NY Times. Users will receive a warning for each illegal download before losing their service on the third infringement.

NO, INTERNET?! That’s human cruelty! I’ll go with decapitation, thanks!

Andy Skelton posted a proposal for a mechanism by which a web server could send related objects to a resource in response to a single request. It’s quite an interesting idea, although I’m not sure how much we could gain given that most clients today do HTTP pipelining.

It could reduce loads on the server, but I’m not sure either. Most static content is served very efficiently on the server using the sendfile (2) system call. By mixing static content with dynamic (the HTML which has to know what its embedded objects are), it may be difficult to implement efficiently.

That said, it could have some merits, and a more in-depth analysis would be needed and I’d be interested to see how it pans out.

Very inspiring lecture by CMU Computer Science Professor Randy Pausch, who was diagnosed with pancreatic cancer and may only have a few weeks or months to live.

Here’s the video:

Aside from the “head fakes”, my biggest takeaway from the lecture is screenprinted below:

Tina Dam and I caught up during ICANN San Juan on the current state of IDN TLD work within ICANN and that was when I first found out that she was putting together a live IDN TLD test bed which includes translations of the string .test into eleven written languages (Arabic, Chinese-simplified, Chinese-traditional, Greek, Hindi, Japanese, Korean, Persian, Russian, Tamil and Yiddish) and ten scripts (Arabic, Cyrillic, Devanagari, Greek, Han, Hangul, Hebrew, Hiragana, Katakana, Tamil).

I was very excited to hear that and wanted to blog about it but there was much to catch up at work so I let it slide.

Two days ago, an update from ICANN on this project:

ICANN today finalized the IDN .test Evaluation Plan and continued taking steps toward insertion of IDN strings in the root zone. Recent changes to the plan are based on comments received on the IDN public forum and also from consultations with ICANN Technical Advisory Committees. This last version was approved by the ICANN Board at their 14 August 2007 meeting. The resolution directs ICANN Staff to implement the IDN .test Evaluation Plan, and report back to the ICANN Board following the conclusion of the evaluation.

Specifically, the Board approved the delegation of eleven evaluative top-level domains representing the term ‘test’ translated into: Arabic, Persian, Chinese (simplified and traditional), Russian, Hindi, Greek, Korean, Yiddish, Japanese and Tamil. Following this ICANN Board approval, the delegation request will now go through standard IANA procedures for insertion of top-level domains into the root zone. The technical evaluations of IDN TLDs and their usability in various applications will proceed following their delegation.

This is a major milestone in the IDN Program Plan and signals a significant step forward towards Internationalization of the DNS. It is currently anticipated that delegation of these TLDs and the evaluations, as described in the plan, will commence in September 2007.

I would like to applaud ICANN (specifically Tina) on bringing the project this far. This is a major undertaking, and an important one too, for the following reasons:

1. It works across the Internet — not just an isolated test that involved a couple of PCs running in a lab environment; they are going to insert these labels into the root zone! This is the only way to involve the most diverse mix of participants in the test bed. The fact that it requires no special setup (like tweaking of hint files) may lower the barrier for entities such as ISP’s, who are traditionally seldom interested in the development of IDN, to participate.
2. As a result, it allows the most diverse array of test cases possible. Just imagine how an innocent domain name gets passed around applications, resolvers, recursive and authoritative DNS servers through a myriad of functions, API calls and networking protocols. It’s supposed to work but who knows for sure?
3. It tests major scripts used by regions with an immediate need for IDN-TLDs (Latin would have induced yawns)

I’m sure there are skeptics and ICANN-haters out there who will dismiss this for time-wasting activity, etc. The truth is, no one has actually tested IDN TLD’s on Internet-wide scale before. And no, country-wide deployments will not suffice because the diversity of software environments and cultures simply isn’t there.

And if you’re a proponent of the Just-do-it school of thought, this should be seen as a move in the right direction. If no major problem was found during the live test, it will shut the mouths of those who are doubtful.

We should take advantage of this test to file bugs for your favourite software vendors and get them to support IDNs! When was the last time IANA inserted a test TLD to the root? Tell them that if IANA agreed to put these test strings in the freakin’ root, this is not a default ignorable technology alright!

So, help spread the word and test the Internationalized Internet!

नमस्ते