>A problem with no solution???? Allow me to introduce JetSend.

Hi Adrian,

I suspect you already know what I'm about to say. =-) Come on, let's be
serious. I know you guys at HP have put in a lot great effort into JetSend
but to imply JetSend can allow any device to handle any data type in a
meaningful and useful way is simply absurd.

>With JetSend two communication appliances *negotiate* (through the JetSend
>protocols) content.  And (this is the clincher) the two devices are
>required to support the JetSend mandatory content format.  This guarantees
>that the two devices will be able to exchange content in a meaningful way.

No. As before, two devices can exchange information if they agree on a
common format, but that's only *half* of the equation. There is no guarantee
such format would be "useful" to the receiving application.

>No matter what JetSend device the PalmOS device connects with meaningful content
>exchange is guaranteed to happen since both sender and receiver must support the
>mandatory JetSend encoding (300dpi, 1-bit mono, RLE compressed raster data).

Nice for imaging devices, but not useful (or even meaningful) for most of
anything else. Suppose I want to send a .RA sound file to a device which
only understands .WAV formats... the default encoding is useless to me,
as are the text and file encodings.

>So, you see, there are efforts being made to solve this "unsolveable" problem.

The problem is not solveable, like it or not. I would like to reformulate 
the problem you originally proposed. Suppose I have an Word97 document on 
my laptop, and SmartDoc on my Palm V.

How would JetSend solve this problem ?

1. Try to send it as a file. Well, that doesn't solve anything, since
   SmartDoc can't read Word97 files.

2. Try to convert the document into a raster image, then send it. Now
   on the Palm side I have an image of the original document. Not
   useful at all!

3. Try to send the document as text. Hmm, JetSend doesn't understand the
   Word97 format, so how could it encode it as vText ? But let's suppose
   by magic the JetSend can re-encode the document as text and send it
   over. Since plain-text isn't a proper Doc document type, I still can't
   read it.

Let's repeat the same experiment but with an AutoCAD file on the laptop and
my proprietary Scribble-CAD on the Palm V. Or let's see if I can send my 
Eudora address book via Jetsend and have Palm's "Address" application auto-
matically import it. How about "BrainForest" on the Palm side to "Jot+"
on the PC side ?

You get the picture. It isn't enough to transfer data in some arbitrary
"meaningful" way. To be useful, this data must be parseable by both ends.
JetSend it is not a universal data transfer adapter. It merely helps two 
ends which *already know how to communicate in some common format* to 
negotiate the best format for data exchange. But what if the two ends
do not share a common format ?

Unless we (re-)write all programs in a particular class to be able to work
with common formats, this problem is unsolveable. Given "n" different formats,
we need at least "n-1" conversion programs. Noting we literally have thousands
of programs with thousands of different formats, JetSend doesn't solve this
problem. As you might say, it only pushes it further up the stack.

Don't get me wrong. I think JetSend is useful, but I think we're kidding
ourselves if we think JetSend can solve the unsolveable. In fact, as a 
practical matter today, I'd say that JetSend has little value outside 
of HP imaging devices. Maybe someday!

Regards,

-Ade

Reply via email to