Month: October 2002

Bill My Phone Risk Factor

I received some private mail asking why I neglected to mention the most important issue: are phone companies willing to take the credit risk.  The underlying assumption I made was that phone companies will replace Visa and MasterCard, not the banks and financial institutions who are in the business of taking credit risk in exchange for fees and interests.  The Market-based Credit Card idea has a chance of being useful in this scenario.

Bill My Phone Feeback

"Scott" correctly points out two main business issues with my Bill My Phone idea:

  1. Phone companies might not want to get into payment business.
  2. Phone companies don't know much about real time payment processing.

I guess it depends on whether phone companies sees payment business as an opportunity or a distraction.

Bill My Phone

This is a variation of Bill Me Later idea that brings phone companies and mobile authentication into the picture.  Payment by phone and authentication by phone are old ideas. Combine them with Bill Me Later along with 3D-Secure and you get: Bill My Phone.

Just like Bill Me Later, transaction starts by pressing the "Bill My Phone" button on a merchant's checkout page.  It uses 3D-Secure variation so the 3D-Secure merchant plugin redirects the customer to a 3D-Secure ACS at the customer's phone company using the customer's home phone number.  A soon-to-be-ubiquitous 3D-Secure authentication window with my phone company's logo pops up.  At this point, the customer can authenticate and approve the transaction using one of three way:

  1. enter password into the popup
  2. enter password into his or her cellular phone (WAP or J2ME)
  3. answer home telephone and press some numbers displayed on the popup.

At this point, the transaction is complete and the purchase amount will be added to the customer's monthly bill.  Obviously, processors like First Data will need to get into the picture, but I think the chemistry is there just waiting to be mixed.

South Korean Nukes

Now that North Korea admited to having nukes, South Korea is likely to revive its own nuke and middle-range missile programs which were shelved long time ago under pressures from the US.  World peace and fairness at odds.  Exciting times we live in.

Noise over Microsoft Testimonials

I can't understand why people are making so much noise over the use of clipart person pictures in the Microsoft testimonials.  Apparently, people are applying different standards to Microsoft than to breasts.  Hey, if it looks too good to be real, it probably isn't.  Besides, I don't think there was anything in the testimonials that said the picture was that of the author.  Its shabby practice, but I doubt anyone making noise now expected anything better from Microsoft before.

Really Simple RSS Extensions

I hate XML Namespaces.  Its ugly and difficult to grep (pun intended).  Its also makes hand coding XML difficult since one has to remember those namespace URIs.  There can be no defense for XML Namespaces, for the controversies over it can not be denied.  While RSS 2.0 introduces XML Namespaces into RSS, I intend to present a simpler approach that does not use XML Namespaces.

In RSS, there are two areas where extensions are most likely, inside <channel> and inside <item>.  To support extensions in these two areas, we introduce three rules:

  1. RSS parsers must ignore unknown tags.
  2. Unknown RSS tags are opaque – this means you cannot enumerate its children.
  3. Encapsulate custom tags inside a tag whose name starts with domain name.

Here is an example:

<channel>
  …
  <com.docuverse.daily.tags>
    <title>semantics of extension tags are context sensitive.</title>
  </com.docuverse.daily.tags>
  <item>
    …
    <org.slashdot>…</org.slashdot>
  </item>
  …
</channel>

This approach to extensions can easily be manipulated using simple regular expression based tools.  Its easy to read and write.  Its namespaces done right.  Its a solution that is willing to sacrifice that problematic 20% in return for simplicity.
   

Syndicated Resources

RSS is currently used for syndicating unstructured textual data, but Web consists of wider variety of resources such as images (see my Syndicated Image and related use cases posts), sounds, movie clips, animations (Flash and SVG), PDF, packages (ZIP, gz, etc.), and structure data (XML).  How do we syndicate these resources using RSS?

Here is one approach.  Add 'type' and 'encoding' attributes to <item> for specifying item's MIME type and encoding method.  Default MIME type is 'text/html'.  There is no default encoding type and unspecified encoding type means it is unknown.  Alternate versions can be use multiple <item> with matching <guid> with order of appearance indicating the order of preference.

Public Channel

An RSS channel typically has one writer and multiple readers.  Some bloggign software allows multiple writers per channel, channel sharing is limited to the deployment site.  How can we have shared channels across sites and writers?

First, feed directory services like syndic8.com and weblogs.com must support multiple channel feeds per channel.  To identify channel, we can either use the channel title or add <guid> to <channel>.  With <guid> approach, title coherency is a problem.

Second, some arrangement must be made to make it easy to subscribe to shared channels.  Client-based approach could start with one feed and find other feeds for the channel either directly from a channel directory service or from the feed itself.  In later approach, each feed is responsible for finding other feeds for its channel.  Server-based approch relies on channel directory services like syndica8.com to provide channel feed aggregation service.

Say Hello to Daily Bot

I am done with an initial pass over my Java RSS Parser.  Its supposed to handle all variations of RSS including 0.9x, 1.0, and 2.0.  Its a forgiving parser designed to handle the meanest and ugliest RSS feeds.  It still requires well-formed XML though.  I'll add a regular expression based version as a fallback parser to handle not so well-formed XML if there is a need.  I'll need more information on variety and quality the feeds out there though.  If you have a RSS feed, this baby will likely visit you sometime over next few days.  Its name is Daily, Docuverse Daily that is.