Writing portable applications

[Mike Meyer]

Ulrich Hobelmann <u.hobelmann at web.de> writes:
> Mike Meyer wrote:
>>> I'd rather develop a native client for the machine that people
>>> actually WANT to use, instead of forcing them to use that
>>> little-fiddly web browser on a teeny tiny display.
>> You missed the point: How are you going to provide native clients for
>> platforms you've never heard of?
> 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.

>>> And again: connections might be slow, a compact protocol is better
>>> than loading the whole UI every time.  And while Ajax might work,
>>> despite the UI being maybe too big for the little browser window, and
>>> even if it works, it's still probably more work than a simple, native
>>> UI.  First of all it needs to load all the JS on first load, secondly
>>> sometimes for a flexible UI you'd have to replace huge parts of the
>>> page with something else.  Native UIs are more up to the task.
>> I'm not arguing that native UI's aren't better. I'm arguing that web
>> applications provide more portability - which is important for some
>> applications and some developers.
> 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.

>>> I just wonder who wrote fully standards compliant web browsers for
>>> those 90 platforms.
>> Nobody. I doubt there's a fully standards compliant web browser
> 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.

>> available for *any* platform, much less any non-trivial collection of
>> them. You write portable web applications to the standards, and design
>> them to degrade gracefully. Then you go back and work around any new
> 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?

>> You think you're done. A lot of developers think you can stop with
>> the
>> first one or two. You're all right for some applications. For others,
>> you're not.  Personally, I like applications that run on all the
>> platforms I use - and your set doesn't cover all three of those
>> systems.
> 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.

>> same thing applies to threads, except such code typically includes a
>> third option of not using threads at all. And so on.
> 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.

>> And we haven't even started talking about the build process...
> 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.

>>>> Of course, considering the state of most of the HTML on the web, I
>>>> have *no* idea why most of them are doing this.
>>> Yep.  Maybe it would be best to reengineer the whole thing as ONE UI
>>> spec+action language, incompatible with the current mess, compact, so
>>> it can be implemented with minimum fuss.  And most of all, I wouldn't
>>> use a MARKUP language, as a real application is not text-based (at
>>> least not as characteristic #1).
>> You mean most of the applications I run aren't real applications?
>> Right now, my desktop has exactly two GUI applications open on it - a
>> mixer and gkrellm. Everything else is characeter based. Hell, even my
>> window manager is character based.
> 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.

>> I think you're right - a web standard designed for writing real
>> applications probably wouldn't start life as a markup for text. The
>> only thing I can think of that even tries is Flash, but it's
>> proprietary so I don't know much about it.
> 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.

>> Care to tell me how you would design such a format if the goal were to
>> *not* lose any portability - which means it has to be possible to
>> design interfaces that work properly on character devices, things like
>> Palms three-color greyscale displays, and devices without pointers or
>> without keyboards, or even in an audio-only environment.
> 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 at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.