[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bluetooth-dev] WAP over Bluetooth, missing profile?
On Fri, 27 Oct 2000 Andreas.Karlsson@xxxxxxx.com wrote:
> You are absolutely right, the existing profile really makes sense in almost
> every cases. But imagine that a system contains a WAP-server and that a
> WML-page should show up on your phone every time you come close to the
> system, e.g. your car. Then maybe it is overkill to use IP, just a thought.
I can imagine that the bluetooth consortium or standardization committee
or whatever it's called know about the overhead with RFComm/PPP/IP/TCP,
and that's why other profiles exist that send data directly (without any
way of routing the information to something outside the PAN). But it's
probably a really complicated problem trying to support both things in the
It's a bit like if the USB-developers had described USB both as an
ethernet replacement and a serial/parallel-replacement. Manufacturers
etc. would not know what interface to put on their products. If you buy an
USB mouse or Bluetooth mouse chances are pretty big you only want to
connect it to a close-by computer, but let's say you want to print a bunch
of SMS'es or emails you have stored in your mobile phone. Is it obvious
that the user always will want to do it on a printer in the local area ?
In your scenario, for the simple case of your car talking to your phone,
yes it's totally pointless to have the IP protocols (apart from the SW
issue of standardized open-source components available). But let's say
that 1 year after this solution has been on the market, people in
parking-lots and garages put up Bluetooth servers, with the intention that
you should be able to check on your car or start the engine heating or
whatever remotely. Now your phone will need to talk real IP or at least a
routable protocol to the Internet, and the parking-lot server needs to
talk IP to the Internet and the "Direct WAP" protocol with the cars. A lot
of bridging and headaches and protocol conversions just because the
original implementation was not routable or standards compliant.
Having said that though, I'd rather have my phone talk to my car in a
proprietary way next year than waiting 5 years for a general solution :) A
compromise as always...
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org