Richard Hartman wrote:
> Yark! The -mandatory- format is 300dpi bitmap!??! You're
> talking memory-limited & sometimes low CPU power devices here.
> Wouldn't it make more sense if the mandatory format were more
> of a lowest common denominator kinda thing (like ASCII) & the
> bitmaps were an optional format?
>
> Bitmaps may transfer a -picture-, but they don't really transfer
> the -information-. An ASCII encoding would ensure the information
> got across in a format that was more likely to be usable ... at
> least to other PDAs, or the humans running them. The bitmap format
> is really only useful for imaging devices like printers & faxes.
>
Remember our objective here. To guarantee that content is exchanged
by all devices in a 'human-readable' format. This includes digital
cameras. You can represent text in image format but not vice-versa.
> IMO you really made the wrong choice for your -mandatory- format,
> and I think you'll be having a lot of trouble getting buy-in
> from the handheld community.
I totally agree with you that the raster format is problematic in
the handheld world. Understand that this is the 'encoding of last
resort'. Hopefully PDA's will *never* negotiate to this format.
But it is there as a fallback in case no other common format is
supported by both devices. What this tells me is that supporting the
'PDA-friendly' encodings in PDA's is critical. Again, I agree with you and I
hope this encoding is *never* used between two PDA's. But it must be
supported. And it actually isn't that bad on the Palm. We've done it.
Pagers might be tough tho! :)
Bob Ebert wrote:
> One consistent problem with that scheme is that there's no good way for
> apps to negotiate for the least loss of content in the data.
JetSend will not beat the performance and quality of the device-driver
model. We understand that. If you tune content format and exchange
protocols for dedicated device-pair combinations you will have better
results than with JetSend.
But can't you see where this model gets us as we move to a world with
thousands of different devices? Little islands of proprietary communications.
I don't think that's what people want.
JetSend is not about obsoleting the device
driver model. But in devices that don't have the resources to model
every receiver they may want to talk to doesn't JetSend make sense?
> Perhaps it's simpler said to note that the Address book can't do a darn
> thing with 300dpi input, so the actual information transfer is 0% for that
> case. ...and it can't do very much with ASCII, not without additional
> rules to parse the text. That's what vCard is for...
Like I said above, I agree with you that 300dpi is almost useless in this
situation.
That *is* what vCard is for. And that is why I would hope two appliances that
hope to communicate contact information negotiate to the vCard encoding.
If they both support the vCard encoding there is 0% chance that the raster
encoding will be used. *Devices negotiate to the highest common encoding*
Raster is never the 'highest common encoding' for a PDA.
But just picture the following interaction. Person A wants person B's contact
information. B has a PalmOS device. But person A forgot his and only has
his digital camera. Both have JetSend. B can still send his contact
information
to the digital camera because they both support the raster encoding. I *agree
with everyone out there* that this is not ideal! It would have been ideal if
A
had his PalmOS device with him. But at least A now has it in a human readable
format.
Ade Barkah wrote:
> 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.
There is if both sender and receiver were sharing information both could "use"
and both supported the JetSend specified encoding designed to communicate
that information.
> >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.
But if JetSend adopted the .WAV format as it's preferred sound encoding and
both devices were good JetSend citizens then the default encoding would
never be used. I'm sensing a theme here; I have to reiterate: the default
encoding is the encoding of last resort. Hopefully, it will never be
used. But it must be supported "just in case". And in that (hopefully) very
small percentage of cases I believe that the users will be more satisfied
having
exchanged that than nothing at all. Like the PDA to camera example above.
(I agree that raster in a sound only device really is useless; I expect we
have a hard decision to make in this arena when we move to support sound
devices with JetSend)
> 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!
EXACTLY!!! Where do you start? In 5 years? In 10? How about now?
Picture the world in 20 years. Imagine all the communicating appliances
around. Imagine the inability to interoperate with all those millions of
combinations. In a sense JetSend is trying to address a problem that isn't
that bad. Yet.
Adrian Pfisterer.
Hewlett-Packard.
