Critique of iec.org "tutorial" about WAP

I'm guessing at the appropriate newsgroups for this topic.
I tried first asking which would be appropriate:
http://www.google.com/groups?selm=vr....supernews.com
:but nobody responded to my query, so now I'm posting blind here.
Please tell me if you know of any more appropriate newsgroup for
general discussions of WAP and related online documents, and among the
ones I'm trying please tell me which are most appropriate.

Linkname: IEC: Wireless Application Protocol (WAP)
URL: http://www.iec.org/online/tutorials/wap/topic01.html
Mobile subscribers can access the
same wealth of information from a pocket-sized device as they can from
the desktop.

I disagree. Most Web content is in huge Web pages that are too large to
download to Nokia 3595, a typical pocket-sized device. There is no
automatic procedure to convert regular Web pages to tiny pieces
acceptable to WAP. Conversion on a page-by-page basis could be done
manually, but it's impossible to keep up with the flood of new Web
pages that appear each day, so at any point in time only an
infinitisemal fraction of the wealth of Web information would ever be
available on a pocket-sized device via WAP.

Based on the Internet model, the wireless device contains a
microbrowser, while content and applications are hosted on Web
servers.

Note: On 2003.Nov.06 I wrote a tiny HTML file for my personal Web site
(part of the Web site on my ISP's shell machine), just to demonstrate
it's now accessible to my Nokia 3595 which I had gotten on Nov.03. Then
on Nov.07 I write a simple CGI application to produce a tiny Web page
also now accessible to my Nokia 3595, and linked it from the Web page
of the previous day. See http://tinyurl.com/uh3t which links to my
little demo Web page. As of that date, I am now available to do this
kind of work for others, and looking for offers of employment and/or
contracts. Please call me on my cellphone if you have such an offer.

Applications will be written in wireless markup language (WML), which
is a subset of extensible markup language (XML).

That's an unnecessary restriction. My demo application which took just
a few minutes is written in Common LISP via CGI (Common Gateway
Interface). Why should people be led to believe they cannot write
applications in any language except XML?? (I'm referring to
server-level applications. Does the word mean something else in the
text I quoted??)

That so-called tutorial I was reading (and commenting-on) doesn't seem
to provide any specifics about what HTML commands (such as <B> which I
tried and know works) are acceptable to the WAP bytecode stream that
connects the InterNet to the handheld device. Does anybody know where I
can find that info? Specifically I want my online content (both static
pages and CGI-generated reports/forms) to be compatible between regular
Web browsers and the WAP-mini-browsers in cellphones, so that I need
deal with only a single format instead of two.

---

› See More: Critique of iec.org "tutorial" about WAP

In article <[email protected]>, [email protected]
([email protected]) writes...

> Linkname: IEC: Wireless Application Protocol (WAP)
> URL: http://www.iec.org/online/tutorials/wap/topic01.html
> Mobile subscribers can access the
> same wealth of information from a pocket-sized device as they can from
> the desktop.
>
> I disagree. Most Web content is in huge Web pages that are too large to
> download to Nokia 3595, a typical pocket-sized device. There is no
> automatic procedure to convert regular Web pages to tiny pieces
> acceptable to WAP. Conversion on a page-by-page basis could be done
> manually, but it's impossible to keep up with the flood of new Web
> pages that appear each day, so at any point in time only an
> infinitisemal fraction of the wealth of Web information would ever be
> available on a pocket-sized device via WAP.



I think the general consensus is that WAP stinks, even more
so because many of the implementations are nearly useless.
It doesn't help that many of the screens used with WAP have
such low resolution.

Not sure where the spec is defined, but I notice some of the
pages over on craigslist.org (not the homepage apparently but
most of the individual post pages) have the following markup
(forward slashes added to prevent HTML renderers from not
showing it literally):


// <meta name="palmcomputingplatform" content="true">



For various reasons, I think the future, or at least the
immediate future, lies with the technology below, and you
can even preview how your pages will look on a small screen
with a "full size" browser:

http://www.opera.com/products/smartphone/smallscreen/



--
* Few people are capable of expressing with equanimity opinions which *
* differ from the prejudices of their social environment. Most people are *
* even incapable of forming such opinions. -- Albert Einstein *
* *
* To send email, remove numbers and spaces: pjkusenet64 @ ekahuna27 . com *
* Simple answers are for simple minds. Try a new way of looking at things. *

> Date: Wed, 19 Nov 2003 02:47:49 -0800
> From: Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
> I think the general consensus is that WAP stinks, even more so
> because many of the implementations are nearly useless. It doesn't help
> that many of the screens used with WAP have such low resolution.

I disagree as to them being useless, but await your rebuttal. Clearly
regular WWW service, designed for full size screens of desktop and
laptop computers, with rapid scrolling from screen to screen within a
single 'page', with a flood of data in each 'page' which the user can
then browse to read or select the desired part, is a different market
from WAP service, whereby the user is restricted to a tiny hand-held
device with a very small screen, and where the total size of each
'page' is absolutely restricted to much smaller than typical WWW
'pages'. For applications that are useful even with the restrictions of
WAP, which are needed in the field where a desktop is definitely not
available and a laptop is hardly ever available, WAP may be useful. One
region of overlap is instant messaging, which really belongs on
handheld devices, but already has such a huge user base on desktops
that the IM-dt market is unlikely to go away soon, leaving a perpetual
overlap.

I think the problem with WAP is that hardly any truly WAP-designed
content is yet availble. The few WAP services I've seen to date
are totally cruddy. For example, the WAP-zone lookup shows an extremely
long alphabetical list of cities within a single state, broken into
groups of ten at a time to fit on a single WAP 'page', with 'Next'
links from each to the next.
http://www.google.com/groups?selm=vr....supernews.com
I think we need to fully implement RPC (Remote Procedure Call) services
to build tools with which we can then implement actual services
accessible from WWW or WAP equally (via slightly different toplevel
interfaces to break the info into different-sized pieces and format it
differently, after RPC has already done the actual info-retrieval
work). Whether .Net or some other RPC is best is anybody's guess.
I'm thinking of implementing some non-.Net version of RPC myself.
Is anybody else interested in such a project? Currently on my Web site
I have a WAP directory which I plan to fill with static Web pages
and CGI applications that are specially designed for WAP access.
Maybe I'll create a RPC directory for experimenting with CGI
applications that are designed to be called from other CGI applications
rather than directly used by WWW or WAP users. The output from such an
application will always be a TEXT/PLAIN listing which is in
machine-parseable format similar to the query language (s-expressions
in both cases to support arbitrary tagged-tree structures of data).
I'll probably support batches of queries within a single HTTP
transaction, to reduce overhead of starting the CGI process each time.
Instead of a very complicated query format that supports lots of data,
there will be a very simple query format that supports just a single
item to be processed, with a whole batch of such queries to satisfy the
customer request. For example, there might be a query type that
provides the longitude and latitude of a given city, and a batch that
does a whole bunch of such for use in building a visual map or a
nearest-neighbor network or finding the nearest store to your current
location etc. (If anybody knows of any already existing RPC services
like that, especially a master index and search engine for finding such
services, regardless of whether they are implemented using .Net or
whatever, please tell me.)

Google groups:
Your search - "index of RPC services" - did not match any documents.
Your search - "search engine for RPC services" - did not match any documents.

> For various reasons, I think the future, or at least the
> immediate future, lies with the technology below, and you
> can even preview how your pages will look on a small screen
> with a "full size" browser:
> http://www.opera.com/products/smartphone/smallscreen/

IMO auto-conversion from huge WWW pages to tiny WAP pages is not a
general solution to the problem. The presentation of the data really
needs to be re-designed from the start to make it WAP-friendly. Instead
of trying to shoehorn the entire WWW space into WAP service, we should
concentrate on implementing some truly WAP-friendly services.

In article <1069546217.204219@rh9cache>, ****Spam-16509963255-
****[email protected] (****Spam-16509963255-****[email protected]) writes...
> > Date: Wed, 19 Nov 2003 02:47:49 -0800
> > From: Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
> > I think the general consensus is that WAP stinks, even more so
> > because many of the implementations are nearly useless. It doesn't help
> > that many of the screens used with WAP have such low resolution.
>
> I disagree as to them being useless, but await your rebuttal. Clearly
> regular WWW service, designed for full size screens of desktop and
> laptop computers, with rapid scrolling from screen to screen within a
> single 'page', with a flood of data in each 'page' which the user can
> then browse to read or select the desired part, is a different market
> from WAP service, whereby the user is restricted to a tiny hand-held
> device with a very small screen, and where the total size of each
> 'page' is absolutely restricted to much smaller than typical WWW
> 'pages'.


See below for comments.

[snip]


> I think the problem with WAP is that hardly any truly WAP-designed
> content is yet availble. The few WAP services I've seen to date
> are totally cruddy.


[snip]

> I think we need to fully implement RPC (Remote Procedure Call) services
> to build tools with which we can then implement actual services
> accessible from WWW or WAP equally (via slightly different toplevel
> interfaces to break the info into different-sized pieces and format it
> differently, after RPC has already done the actual info-retrieval
> work). Whether .Net or some other RPC is best is anybody's guess.


RPC is an extremly insecure network methodology on public
networks and is regularly hijacked by hackers to break into
systems. I don't think I can support that.


[snip]


> > For various reasons, I think the future, or at least the
> > immediate future, lies with the technology below, and you
> > can even preview how your pages will look on a small screen
> > with a "full size" browser:
> > http://www.opera.com/products/smartphone/smallscreen/
>
> IMO auto-conversion from huge WWW pages to tiny WAP pages is not a
> general solution to the problem. The presentation of the data really
> needs to be re-designed from the start to make it WAP-friendly. Instead
> of trying to shoehorn the entire WWW space into WAP service, we should
> concentrate on implementing some truly WAP-friendly services.


The simple fact is, webmasters and websites are _NOT_ going to
make parallel versions of sites simply to appease the currently-
microscopic WAP browser market. In particular, webmasters and
the companies that pay them have shown a nasty inclination over
the last 5 to 7 years to stuff more and more gratuitous crap
into webpages, not least because the marketoons insist on "glitz
and flash" and trying to make corporate websites emulate television.

You can't even get major corporations to produce sites which
site-impaired users can navigate, or people without high-res
computers that play animation and run proprietary IE-specific
scripts, much less ridiculously limited WAP browsers.

It's for these reasons that I believe the only technology that
will get much traction in the immediate future is something like
what Opera is doing. Bear in mind that portable devices are
tending to get higher and higher resolution screens, so this
helps make such things more feasible than they once were.



--
* Few people are capable of expressing with equanimity opinions which *
* differ from the prejudices of their social environment. Most people are *
* even incapable of forming such opinions. -- Albert Einstein *
* *
* To send email, remove numbers and spaces: pjkusenet64 @ ekahuna27 . com *
* Simple answers are for simple minds. Try a new way of looking at things. *

> From: Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
> RPC is an extremly insecure network methodology on public
> networks and is regularly hijacked by hackers to break into
> systems.

Are you referring to all forms of remote procedure call, or only
specifically to Sun's RFC1831? If the RPC server honors only specific
requests that are not able to cause intrusion, how does it get hijacked
to break into a system beyond what services were offered anyway?

> webmasters and websites are _NOT_ going to make parallel versions of
> sites simply to appease the currently- microscopic WAP browser market.

I'm not suggesting that a vast majority of Web sites would be suitable
for making available in WAP format. Merely for services that provide
information that somebody away from home might need, such as how to get
somewhere (a combination of what Yahoo Maps does now and what public
transit agencies ought to do but don't except by voice phone before 5PM
when their office closes).


> webmasters and the companies that pay them have shown a nasty
> inclination over the last 5 to 7 years to stuff more and more
> gratuitous crap into webpages, not least because the marketoons insist
> on "glitz and flash" and trying to make corporate websites emulate
> television.

Yeah, I've noticed that. It's almost DIFFICULT to find what you really
want through all eyeclutter. The really bad thing is the active buttons
and the mere glitz are so indistinguishable from each other that when
I'm on a new WebSite with a full browser it takes me a long time to
find where the main menu or whatever is located.

> You can't even get major corporations to produce sites which
> site-impaired users can navigate,

I agree. Whether somebody actually blind or nearly blind using an audio
or tactile device, or merely somebody with attention deficit or weak
eyesight who gets confused by all the eye-clutter.

> or people without high-res computers that play animation and run
> proprietary IE-specific scripts

Mostly the only animation I see, except on the NASA/JPL sites where
there are some animations of either simulations or sequences of images
as a spacecraft approaches a target, is dancing icons and
advertisements, which are not what I'm trying to look at and which are
constantly distracting me from what I'm trying to read. Except for the
space stuff where animation is the purpose, would you summarize the bad
examples you've encountered where the information you actually wanted
to read was presented through animation etc. where all it really needed
was simple images or HTML?

On the other hand, I've suffered sites which worked fine until suddenly
they switched most of their command buttons from HTML to JavaScript,
which doesn't work here on VT100 dialup into Unix shell, nor I suppose
would work on WAP. For example, Yahoo! Mail used to run in HTML, but
now almost all the commands require JavaScript, so I can't use them
from home, so Yahoo! Mail is nearly useless to me nowadays. (Even the
complain-about-spam button is now JavaScript, so I can't even complain
about spam from home!)

> I believe the only technology that will get much traction in the
> immediate future is something like what Opera is doing.

I'm not familiar with that term as you use it. Because opera is a
common music term, I don't think I'd be able to find what you're
talking about using that keyword in a search engine. Would you please
point me to where the Opera you're referring to is being discussed or
described or defined?

As for the general thesis: The nice thing about the RPC idea is that
one server can deal with the actual work of fielding questions and
providing information, while other servers can provide the interface
between the RPC server and the end user. So we might need only a few
interface servers to handle a large number of different services that
are provided by RPC (in the generic sense, not necessarily Sun's RFC).
A few of us volunteers/activists could set up a few RPC services, and
interfaces between them and a few formats of Web access (M$IE, lynx,
and WAP, as a starter), and then all anybody else would have to do to
provide a new service via our interfaces is to write them as RPC
servers and advertise them through our interfaces. And anyone wishing
to interface to a new kind of device not compatible with WAP would
merely write the interface server then link it to the existing RPC
servers.

****Spam-16509963255-****[email protected] wrote:

<snip>

>> I believe the only technology that will get much traction in the
>> immediate future is something like what Opera is doing.
>
> I'm not familiar with that term as you use it. Because opera is a
> common music term, I don't think I'd be able to find what you're
> talking about using that keyword in a search engine. Would you please
> point me to where the Opera you're referring to is being discussed or
> described or defined?
>

Opera is not only music, but a web browser that is small, fast and only $39
for PCs. They also have a browser for mobile devices.

More info available at their website (http://www.opera.com)