| Mike Meyer 2005-08-28, 6:57 pm |
| Ulrich Hobelmann <u.hobelmann@web.de> writes:
> Mike Meyer wrote:
> Who says I have to? With open protocols, everybody can. I know many
> platforms that STILL don't have a browser that would work with most
> websites out there. They all have NNTP, SMTP and POP
> clients. Text-mode, GUI-mode, your choice.
The people who are distributing applications via the web. You want to
convince them to quit using web technologies, you have to provide
something that can do the job that they do.
> Like Java provides more portability. Unless you ran NetBSD in 2003
> (there was no Java back then that worked for me), hm, IRIX?, Plan9,
> BeOS the list goes on... LOTS of platforms don't have the manpower to
> develop a client that renders all of the huge bloated wagonload of W3C
> tech that was only designed for *markup* from the beginning.
I'm still waiting for an answer to that one - where's the Java toolkit
that handles full-featured GUIs as well as character cell
interfaces. Without that, you aren't doing the job that the web
technologies do.
> Nobody, huh? Then how could you run just ANY web application on those
> platforms?
The same way you write POSIX applications in the face of buggy
implementations - by working around the bugs in the working part of
the implementation, and using conditional code where that makes a
serious difference.
> Oh right, they degrade gracefully. So without Javascript or cookies
> (the former is often not implemented) you get a HTML page with an
> error notice -- if you're lucky.
You left off the important part of what I had to say - that the
application be written by a moderately competent web author.
> A server AND client for a simple protocol designed for its task
> (i.e. not FTP for instance) can be implemented in much less work than
> even designing even part of a web application backend that does that
> kind of stuff.
Well, if it that easy (and web applications are dead simple), it
should be done fairly frequently. Care to provide an example?
> Ok, I'd be interested to hear what those are. VMS, RiscOS, Mac OS 9...?
FreeBSD, OS X and a Palm Vx.
> If a system's scheduler, or select implementation sucks, though, I'd
> complain to the vendor or simply abandon the platform for
> another. Competition is good :)
Complaining to the vendor doesn't always get the bug fixed. And
refusing to support a platform isn't always an option. Sometimes, you
have to byte the bullet and work around the bug on that platform.
> Well, who doesn't do threads after several years of POSIX IMHO can't
> be taken seriously. Ok, the BSDs didn't until recently, but those are
> volunteer projects.
Not all platforms are POSIX. If you're ok limiting your application to
a small subset of the total number of platforms available, then
there's no advantage to using web technologies. Some of us aren't
satisifed with that, though.
> If the libraries are installed, just build and link it (if you use
> standard C, POSIX + 3rd party libs that do the same). If not, then
> tough luck -- it couldn't even run in theory then.
You have to have the right build tool installed. Since you use BSD,
you've surely run into typing "make" only to have it blow up because
it expects gmake.
> I meant not using text elements. Of course it includes text, in your
> case predominantly. But even most curses clients have other elements
> sometimes, like links. A standard spec language could cater easily
> for text clients, but a text language like HTML has a harder time to
> cater for good GUI clients. Most apps I use have buttons and menus
> that I wouldn't want to express with markup (and web pages that try to
> do that most invariably suck).
Well, marking up text is a pretty poor way to describe a UI - but
anything that is going to replace web technologies has to have a
media-independent way to describe the UI. One of the things that made
the web take off early was that anyone with a text editor could create
web pages. I think that's an important property to keep - you want the
tools that people use to create applications be as portable/flexible
as the applications. Since most GUI's are written in some programming
language or another, and most programming langauges are still flat
text, a GUI description as flat text exists for most GUIs, so this
requirement isn't a handicap.
> Java has been mentioned in the other response, but there's also all
> other kinds of application frameworks. Only XUL is markup based, with
> the effect that there's almost no text at all between the markup tags
> I guess ;)
You don't have to guess - finding examples of XUL isn't hard at all. I
think XML gets used in a lot of places where it isn't appropriate. One
of the few places where it is appropriate is where you want a file
format that lots of independent implementations are going to be
reading. This could well be one of those times.
> Colors can be sampled down. Even the new Enlightenment libs do that
> (they say). For mapping a GUI client to a text client, ok, tough.
> Face it, lots of things just can't be expressed in pure text. Images,
> PDF viewing, video, simulation with graphical representations...
Applications aren't one of those things. Even applications that work
with those things don't need GUI interfaces.
> Pointers could be added to any kind of machine, and even without it,
> you could give it a gameboy-style controller for cursor movement
> (i.e. arrow keys).
Yeah, if you're willing to tell your potential users "Go out and buy
more hardware". If you're Microsoft, you probably do that with the
addendum "from us". Not being Microsoft or a control freak, I want
applications that work with whatever the users already have.
> I'm just not talking about a language for audio- and text-mode clients ;)
Then you're not talking about replacing HTML et. al.
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
|