Mike Schaeffer's Blog

June 19, 2007

Last October, I upgraded my Sony Ericcson T637 with a Cingular 2125 Smartphone. While the 2125 has since been discontinued, it's very closely related to the current Cingular 3125. The major differences between the two are that the 3125 has more memory and a different form factor; the 3125 is a flip phone rather, and the 2125 is 'candybar' style phone. Either phone has dramtically more capability than the t637.

When I bought the 2125, I had a couple main goals in mind for the upgrade. The first was e-mail integration with my employer's Microsoft based e-mail account. My second goal was to get mobile internet access for my laptops, meaning access to the web as well as to ssh and Windows remote desktop sessions. The 2125, priced at $100 with a subsidy and a rebate, was one of the cheapest ways to get at that set of features. It is a Windows Mobile 5.0 Smartphone, with a USB interface, 200MHz ARM9 class processor, 64MB RAM, QVGA display, and an EDGE network connection. Even at the time the specifications were not best in class, but it did provide the essentials, and the display was (is) gorgeous. By and large, the phone has done a good job of doing most of what I expected it to.

For me, the best aspect of the 2125 is its integration with Microsoft Outlook e-mail. Since my employer supports Microsoft's [Direct Push](http://www.microsoft.com/windowsmobile/articles/directpush.mspx) e-mail, the phone can be easily (five minutes or less) be configured to synchronize with my corporate e-mail account. Once the connection is configured, the phone maintains an active HTTP connection to the host Exchange server. As incoming e-mails arrive, the server immediately sends them back up to the phone via this connection. Once the phone receives a message, it does what you'd expect and adds them to a list, displays a notification icon on the home screen, and optionally vibrates or makes a noise. In short, it's almost idiot-proof to setup, and works exactly like every other form of text messaging on the phone. If you don't like the idea of continually being bombarded with incoming mails (or the idea of a continually open HTTP connection bothers you) the phone can be configured either to periodically poll for new mail or wait for an manual request to synchronize. Better still, there are seperate configuration options availble for user-definable 'on-peak' and 'off-peak' times. In my case, I generally leave the phone set to automatically accept incoming mails from 7:00AM to 7:00PM, and then manually synchronize otherwise.

For me, e-mail synchronization is the single best feature of the phone. I'd even go so far as to say that the jump to having mobile e-mail access has been as important a difference to me as the jump to having a mobile phone in the first place. While telephone connectivity is both immediate and universal, most of my important work-related communications happens over e-mail. Maybe it's just my job, but I get work related mails at least twenty to thirty times more often than I get work related phone calls. Not having mobile e-mail access basically means a choice between either being tied to a computer or entirely giving up access to that flow of information. In a sense, mobile e-mail access has been for me a liberating thing, a way to stay 'in the loop' but not stuck in front of a desk. The control the phone offers over its synchronization schedule then makes it easy to get 'out of the loop', assuming you have the self-discipline to not request manual synchronization too often. In practice, this has not been much of an issue for me to date. (I do not think my wife would disagree... most of the time.)

One of the pleasant suprises of the phone's e-mail features has been their integration into the other parts of the telephone. Like others, the e-mail client makes an effort to guess at 'important' content in a message: things like URL's and e-mail addresses, but also including phone numbers. Selecting a phone number in an e-mail message gives you the option to either dial the number or add it to your contact list. All of a sudden, all of those e-mail signature blocks containing phone numbers take on a whole new use. Phone number recognition also works with text messages, which pairs nicely with the part of AT&T's directory assistance service that sends text messages containing requested directory information. The phone can also use its connection to an Exchange server to provide access to the server's global phone directory. It's not integrated into the phone's standard address book and it requires an explicit search command, but that's probably a good thing considering the size of some corporate directories.

While the e-mail integration has been really useful, the other internet capabilities have been considerably less so. It is possible to tether the phone to a laptop. It is also possible to use that connection to access the web and ssh connections. However, between the fact that AT&T charges $60/month for the right to tether the phone to a laptop and the connection you then end up with is basically EDGE, it's really not as useful as I thought it'd be. For me, the low bandwidth of EDGE wasn't the problem, but the high latency was. While EDGE is two to three times faster than dial up, it takes on the order of 200-300 milliseconds for a packet to make a round trip. For interactive use of protocols like ssh, this means it can take half a second from the time you press a key on the keyboard to the time it appears in the terminal window. The net result is that an ssh session over EDGE is worse than how I remember 300 baud connections to BBS's. While I'll admit that my memory might be a bit cloudy, I can say this with certainty: despite the lower bandwidth, 56kbps dialup is far more usable than EDGE for this kind of application. More modern services like Sprint's EVDO network do not have this problem, and are probably closer to being worth $60/month. As things are now, I've dropped the $60/month tethering surcharge and stuck with a $20/month data plan that gives me unlimited data to the phone only. While I can still tether the phone to a laptop, this gives AT&T the theoretical right to charge me a per-byte amount for data the phone sends and receives when tethered to a laptop. While they do not seem to do this in practice, I confine my mobile internet access to the phone only. Thanks to the nicer display on the 2125, this is actually a usable way to read text-only web pages and blogs, which is an improvement over the Sony t637.

One other feature worth calling out on the 2125 is the fact that the directory and call history are both integrated into dialing. As you start dialing a number, the phone builds a list in real time of all matching contacts, by number and name, both in your phone book and in your call history. As the list is built, you can use the joystick to navigate through it, select a match, and either dial it or display its details. The only glitch in the logic is that the list presents matches from the call history with a higher priority than matches from the directory. If someone in your directory calls you and you miss the call, this means that the first entry in the list of matches will be the match from the missed call, and not the match from the directory. When you select the entry to see the details, what you'll see is the time the call was missed, and not the other numbers you have for that contact. If you want to call them back on a different number from the number from which they called you, this ends up adding a few steps to find the directory entry.

While a lot of the features I mention above stem from the fact that the phone runs Windows Mobile 5.0, this is not something I've really focused on in this post. I didn't care about the OS the T637 ran, and for the most part, it's been the same for this phone too. While it's theoretically possible to find all sorts of wonderful applications and games for Windows phones, I haven't found anything I can't live without, and neither AT&T nor Handango have done a good job helping me spend my money on mobile software. AT&T seems not to sell Windows Mobile software at all, and Handango makes you download a custom catalog application to see their software offerings for the phone; This catalog application did not work properly for the one application I tried to buy. I wish this situation was better, since I would be willing to at least buy a few games for the phone, and the one game I have installed right now, a clone of Scorched Earth, is good enough that it seems likely the platform could support some great applications and games. Even without games, this phone has been a nice upgrade, and it came at a reasonable price. Compare this with something like the iPhone, and it's hard to get all that excited about spending five times more money for a phone with no e-mail integration, the same lousy EDGE network, and even less opportunities for outside software.

June 12, 2007

I just saw this story on Oregon Trail over on Slashdot. I was born in 1975, which puts me in grade school in the early 1980's, the prime time for these early Apple ][ educational games. As much as I liked Oregon Trail, I liked Rocky's Boots even better. The basic premise of Rocky's Boots was that you had to use basic boolean logic circuits to build machines to solve particular tasks. You ran around a little maze using a very early 'point and click' style user interface to gather parts and put them together. Once you were done, you got to watch your creation do its thing. A fun little bit of trivia regarding Rocky's Boots is that it was developed by Warren Robinette, the creator of Atari 2600 Adventure, including the famous, ego-driven easter egg.

May 21, 2007

Tomorrow, my employer is replacing my three year old Dell D400 with a nice new Compaq nc2400. I have to admit that I'm a bit apprehensive about the switch; My D400 works quite well and shows few signs of decay. But, I also remember feeling the same way about the D400. Maybe the Compaq will be as good as the last Compaq I regularly used and be another nice suprise. Anyway, as part of clearing out the old machine, here are a few links I've found that I'd like to preserve. No promises on content, but you might find at least one of them to be interesting if you read this blog.

Tags:tech
May 15, 2007

The other day, I created a table in Oracle with the following command. This is written in the subset of SQL known as DDL, or Data Defintion Language.

CREATE TABLE COMMON.SAMPLE_TABLE (
  NAME      VARCHAR(64) NOT NULL,
  STATUS    CHAR(1),
  X_C       NUMBER (10),
  Y_C       NUMBER (*,10) NOT NULL, 
  Z_C       NUMBER (*,10),
  FOO       VARCHAR2 (18) NOT NULL, 
  BAR       DATE,
  BAZ       TIMESTAMP
 )
/

Once the table is created, it is then possible to ask the database to describe the table:

common@XE> desc COMMON.SAMPLE_TABLE;
 Name                          Null?    Type
 ----------------------------- -------- ----------------------------
 NAME                          NOT NULL VARCHAR2(64)
 STATUS                                 CHAR(1)
 X_C                                    NUMBER(10)
 Y_C                           NOT NULL NUMBER(38,10)
 Z_C                                    NUMBER(38,10)
 FOO                           NOT NULL VARCHAR2(18)
 BAR                                    DATE
 BAZ                                    TIMESTAMP(6)

For some reason, the syntax of Oracle's description of the table's definition is entirely different than the syntax of the DDL used to define the table in the first place. Not only does the description not use DDL, minor details are different too. For example, the relative placement of the nullability (NOT NULL) of a column and its data type is reversed from one representation to the other. This makes converting a table description into corresponding DDL a trickier process than it would be otherwise. Another difference (loss?) is that the DDL syntax allows for table specific attributes and the description syntax does not. That means that the table's full description really might look something like this:

CREATE TABLE COMMON.SAMPLE_TABLE (
  NAME      VARCHAR(64) NOT NULL,
  STATUS    CHAR(1),
  X_C       NUMBER (10),
  Y_C       NUMBER (*,10) NOT NULL, 
  Z_C       NUMBER (*,10),
  FOO       VARCHAR2 (18) NOT NULL, 
  BAR       DATE,
  BAZ       TIMESTAMP
 )
LOGGING 
NOCOMPRESS 
NOCACHE
NOPARALLEL
MONITORING
/

So, if you rely on a table description as the basis for creating a duplicate copy of a table, you not only have to do specific work to convert the description from description syntax to DDL, the DDL you end up with will likely be incomplete. While I am sure that there is an excellent reason for the syntactic split between the two types of table descriptions, I honesly cannot think of it. My current best theory is that SQL*Plus and SQLNET cannot handle non-table returns from a database request. Because of this, the table description has to itself be a table. You could even make the argument that this is the 'right' way to do things, since it gives you a table description in a form (a table) that database code should easily be able to manipulate. However, the description is itself incomplete, so I'm not sure how useful that explanation is.

I'm not a database guru, but it seems like another way to handle this possible limitation is to have the table description query return a one row, one column table with a BLOB or VARCHAR2 containing the DDL description. SQL*Plus could then special case the display of this query to make it look nice on the screen. (SQL*Plus already does special case desc queries, since their display does not honor calls to SET PAGESIZE. If you really do need table information in tabular form, there are always the ALL_TABLES and ALLTABCOLS views. (Of course, a really wonderful solution to all of this would be to make those views writable, somehow standardize them, and then skip the DDL entirely. :-)

Older Articles...