Mike Meyer wrote: > If your web apps are well-written, any of them should work. As > previously stated, Sturgeon's law applies to the web, so chances are > good they aren't well-written.
:) >> But as soon as some user of platform 54 tries your website, she'll >> encounter some weird behavior without even knowing why. And maybe so >> will you, especially if you don't have that platform there for >> testing. I don't understand how this web thing changes anything... > > The only difference is that the user of Platform 54 has a chance to > use your app. Sure, it may not work because that platforms bugs are > radically different from the bugs in the platforms you tested > on. Raising the possibility of your app working from "no way in hell" > to "maybe" is significant. Ok, there's a chance... >> With POSIX at least you have a real bug-report for the guy responsible >> for it. If a platform keeps being buggy, with no fixes coming, screw >> them. Every user will see that sooner or later, and these platforms >> die. Even Windows is quite stable/reliable after 10+ years NT! > > You do? All your porters reliably give you bug reports? Can I have > some? No, I mean, when you compile something on POSIX and it doesn't work, you have a bug to report. Of course many vendors might ignore them, and often don't send you any feedback at all (unfortunately), probably because contact between the company's programmer and you is considered bad for some reason (I'd consider it good support). > These don't answer the question. Maybe because I didn't explain it > fully. Do you have an example of an application that implements a > simple protocol along with a client and server where HTTP+HTML were > considered as an alternative, and rejected as "more difficult" than > the path actually chosen? No, because I don't know who considered HTTP+HTML before going the other way. HTTP certainly is used increasingly (for XML transfers, WebDAV, RSS, ...), because it's quite simple widely implemented. But as I said, there's RSS as a new standard, there's DAV and others. They don't use HTML, because custom protocols can be easy but have advantages. I guess it differs. Some applications make a lot of sense in a hypertext context; others don't. >> There's NNTP. There's RSS. There's Atom. The latter two emerged >> quite painlessly, even though you could maybe use some website for >> what they provide. But this way you have lots of clients for lots of >> platforms already. > > NNTP predates HTTP. Atom (and I assume RSS) uses HTTP as a transport, > so there's no new protocol invovled - just a new file format. Yes. I consider HTML a kind of protocol in that sense, though. It's a format, and it needs interpretation, too. >> Sure, but you can tell your customers that unfortunately their system >> vendor refuses to fix a bug and ask THEM to ask that vendor. Boy, >> will they consider another platform in the future, where bugs do get >> fixed ;) > > Yup. You and that platform vendor are no win the set of vendors that > don't fix bugs. Personally, I'd rather provide a workaround and keep > the customer. Short-term definitely. Long-term I'd try to migrate the customer (depending on how much influence I have in their IT context). >>> 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. >> Sure. You have to look where your users are. Chances are that with >> obscure systems they can't use most web-apps either. > > Right. Chances are they can only use well-written ones. If you write > those, your stuff will stand out for them. Very good point. You give me back my faith in web-apps ;) >> That's true, though I think the future of development lies in >> overcoming that program-code-as-text thing (NOT visual programming, >> just tool-based, structured). Smalltalk did it decades ago. > > Last time I looked at smalltalk, it still presented program code as > text. So I think you need to clarify what you mean. You have class and method browsers, while most Java and C code is still edited file-wise (though with options to hide methods except for their declaration header). I think it makes sense to ignore the file thing and just use browsers like that (kind of like having every C function in one file, but with the headers and visibility of functions managed by your IDE/build system, not by you by hand. >>> 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. >> Maybe, but for applications that aren't predominantly concerned about >> text, I'd really rather use a structured data type (like >> s-expressions), not text markup like XML. For hypertext, XHTML is >> fine, though, if a bit verbose. > > I'd rather use something which has a formal mechanism for defining > what legal documents are. XML provides DTDs. If you really want > S-expressions, we could use an SGML DTD that let you write them, and > get the best of both worlds. Well, sometimes, sure. But quite often I think people don't bother with DTDs anyway (and of course you could design a DTD format for sexps and write a validator; I'd even guess there exists at least one somewhere out there). Lots of customers will probably ask for XML, so that mostly the way to go. -- 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 -- http://mail.python.org/mailman/listinfo/python-list