Writing portable applications (Was: Jargons of Info Tech industry)

[Ulrich Hobelmann]

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.

>> 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 started writing web apps when I was doing internal tools development
>>> for a software development company that had 90+ different platform
>>> types installed inhouse. It was a *godsend*. By deploying one
>> If that's 90+ GUI platforms, then I agree.
> 
> Why do you care if they are GUI or not? If you need to provide the
> application for them, you need to provide the application for
> them. Them not being GUI just means you can't try and use a standard
> GUI library. It also means you have to know what you're doing when you
> write HTML so that it works properly in a CLUI. But your native app
> would have to have a CLUI anyway.

Ok, UI then ;)
I don't care what UIs people like and use.

>> 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?

> 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.

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.  Plus you're not bound by HTTP request structure, you can use 
publish/subscribe or whatever communication style you want for efficiency.

> bugs you've uncovered in the most popular browsers - which
> historically are among the *worst* at following standards.
> 
>> If you have one Windows GUI (maybe C#), one Mac GUI (Cocoa), one Gtk
>> GUI for X, you're done.
> 
> 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...?

>>> well-written app, I could make everyone happy, without having to do
>>> versions for the Mac, Windows, DOS (this was a while ago), getting it
>>> to compile on umpteen different Unix version, as well as making it
>>> work on proprietary workstation OS's.
>> Well, stick to POSIX and X APIs and your stuff should run fine on
>> pretty much all Unices.
> 
> You know, the same kind of advice applies to writing portable web
> apps. Except when you do it with HTML, "portability" means damn near
> any programmable device with a network interface, not some relatively
> small fraction of all deployed platforms.

Only that even years ago lots of even small platforms would run X, but 
even today MANY platforms don't run a browser with XHTML/HTML4+JS+CSS 
(well, okay, the CSS isn't that important).

>> I never understood those people who write all kinds of weird ifdefs
>> to on all Unices. Maybe that was before my time, during the
>> Unix wars, before POSIX.
> 
> There were standards before POSIX. They didn't cover everything people
> wanted to do, or didn't do them as fast as the OS vendor wanted. So
> Unix vendors added their own proprietary extensions, which software
> vendors had to use to get the best performance out of their
> applications, which they had to do if they wanted people to buy/use
> them.

Performance?  Hm, like epoll/kqueue vs select?  Can't think of examples 
here, but I pretty much only know BSD/POSIX.

> That's still going on - people are adding new functionality that isn't
> covered by POSIX to Unix systems all the time, or they are adding
> alternatives that are better/faster than the POSIX version, and there
> are lots of things that applications want to do that simply aren't
> covered by POSIX. And not all implementations are created equal. Some
> platforms malloc's provide - to be polite - less than optimal
> performance under conditions real applications encounter, so those
> applications conditionally use different malloc implementations. The

Well, OF COURSE malloc is ONE general purpose function that HAS to carry 
some overhead.  I routinely use my frontend(s) for it, to cluster 
allocations locally (for caching and alloc performance).  Matter of a 
100 LOC usually.  No problem at all.

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 :)

> 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.

> 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.

> Basically, deciding to write to POSIX is a decision to trade away
> performance on/to some platforms for portability to more
> platforms. It's the same decision as deciding to write a web app,
> except the tradeoffs are different. Each of the three solutions has a
> different set of costs and benefits, and the correct choice will
> depend on your application.

I'd like to hear about those performance problems...  If someone can't 
make the standard calls efficient, they should leave the business and 
give their customers Linux or BSD.

>> And if it's not Unix, what's a prop. workstation OS?
> 
> They've mostly died out since then. At the time, there were things
> like Domain and VMS. 

Never heard of Domain, but VMS is called NT/2000/XP/2003/Vista now (with 
some enhancements and a new GUI). ;)

>>> 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).

> 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 ;)

> 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...

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).

I'm just not talking about a language for audio- and text-mode clients ;)

-- 
My ideal for the future is to develop a filesystem remote interface (a 
la Plan 9) and then have it implemented across the Internet as the 
standard rather than HTML.  That would be ultimate cool.
	Ken Thompson