Re: Maybe Safari 4 actually is for Windows

In article <hsGdnQp4c8XmIzfUnZ2dnUVZ_hOWnZ2d@xxxxxxxxxxxxx>,
"Dan Johnson" <danieljohnson2@xxxxxxxxxxx> wrote:

"ZnU" <znu@xxxxxxxxxxxx> wrote in message
news:znu-2203F7.10074101032009@xxxxxxxxxxxxxxxxxxxxxx

[snip]

Let me see if I can articulate this better. Web apps largely break down
the traditional barrier between data and tools, instead utilizing what
we could call "smart data". Automatic persistence at uniquely
addressable locations in the cloud, the fact that editing functionality
comes along with the data automatically, and web UI conventions like
in-place editing, all contribute to this.

I see nothing here that distinguishes web-apps from normal apps,

Normal desktop apps can have their individual views accessed from
anywhere in the world using a globally unique identifier?

I notice you had to cut me off midsentence there, so you could pretend I
didn't address this.

Questioning whether "cloud" and "Internet" don't mean the same thing
doesn't actually address this.

except for the overused buzzword "cloud", which as far as I can see,
just means "internet".

It means, I think, the data and services available on the network, as
distinct from the network itself.

That is what the "internet" is usually used to mean.

And using the term "cloud" for it is more precise. It also serves to
situate the discussion within a specific context, since the term is
generally associated with a particular understanding of how
Internet-based data and applications are to be conceptualized.

[snip]
You do get this behavior with applications too. OLE does this.
Admittedly, those aren't URLs, but the principle is the same.

Distributed object systems theoretically could form the basis for this
sort of thing in desktop applications. But they aren't used that way in
practice.

They are available to be used if desired. It's not like nobody has a copy of
Office. Mostly they do not use them this way; perhaps they don't want this
particular thing.

They are not available to be used this way by individual end-users. It's
not routine, standard behavior that a spread*** (or whatever) that I
can create on my desktop computer gets a unique address in the cloud,
and I can pull up all the data (and tools to work with it) from any
other Internet-connected computer in the world.

While Basecamp is obviously an application in the technical sense, it's
*not* an application if one considers things slightly more abstractly.
A Basecamp project is just a collection of web pages that document a
project. They just happen to be "smart" pages that contain embedded
tools for modifying their contents in useful task-specific ways.

This does not shed any light on anything.

And at this point I'm starting to suspect that's because you have your
eyes closed.

Ah, well, I suspect it is because you are trying to veil your meaning in
clouds of verbiage.

I think if I can clearly articulate the difference, it will no longer seem
like an advantage for web apps. Let me have a go at it:

There is something web apps do that desktop apps don't, and if desktop apps
did it, we'd not recognize them as "real" desktop apps. Web apps are run on
a central server, and the UI is experienced through a dumb terminal.

Well, first off, that's actually pretty useful, for some types of apps.
Secondly, in order for this to actually be equivalent, these remotely
accessed apps would have to implement a bunch of specific behaviors that
aren't necessarily implied by your simple description, in terms of the
way they handle access to data. And if you implemented the most
significant of these (the globally unique addressability of specific
views), you'd be halfway to recreating the web.

I'm not sure I've explained well enough how important that globally
unique addressability thing is. The fact that all of these components of
applications are accessible in a common context (the browser) via unique
identifiers (the set of all valid URLs) is precisely what creates the
"cloud" out of what would otherwise be discrete entities.

OK, your web browser is perhaps not *as* dumb a terminal as a VT100, but it
is still pretty dumb. The UI you can provide is severely constrained. Even
if HTML could provide a really good UI in and of itself, web apps still
would not integrate well with the desktop, or desktop apps. They would be
isolated, for security reasons. This isn't a deficiency of web browsers, but
hard-won virtue. Yet, at the same time, it dooms web browsers to an inferior
UI experience.

The cloud and the desktop are not very well integrated at the moment.
You're trying to present this as a problem that only runs in one
direction: it's a problem for cloud apps that they can't access local
data.

But of course this is nonsense. There are two islands of data here;
there's the data that lives on the Internet, and there's the data that
lives on local storage. And cloud apps tend to integrate better with the
former while desktop apps tend to integrate better with the latter. This
is a problem, but it's a problem from both directions, and people are
working from both directions to solve it.

Now, the web apps you've been talking about have something else wrong with
them- they are hosted by 3rd parties. You are therefore taking a number of
risks if you put your data up there. For one thing, you don't control the
update schedule. If an update breaks the service, or removes some feature
that is important to you, you are just screwed.

Another problem is that data hosted in this way may not be very private.
Some of these companies have a privacy policy that amounts to "all your data
are belong to us"; and even those which do better can change their privacy
policies. Your data may be data-mined and use to advertise to you, for one
thing. Or perhaps just made public.

You are also at the mercy of these companies' security policies. Maybe
theirs are better than yours, or maybe not. You have no way to tell.

Naturally, you can (and people do) host web apps internally, on a local
network.

Yes. You have the option to do it either way.

Many of these objections are obviated if you do this- but many of
the virtues you've touted are also lost, or at least mitigated.

Some of the generally touted virtues are lost, yes. The conceptual
differences I've been discussing in this thread, however, remain.

This is a theory which has led to many unsuccessful Office
programs.

It is true that most documents do not require the full power of
Microsoft Office. Each one uses a small subset of the total
features. But there is a great diversity of documents in the
world, and a 'just-what-you-need' Office product is generally
suitable for only a small subset of them.

There's not a lot of people who would just settle for WordPad.

As I said, Google Docs isn't a general replacement. But it has pretty
obvious advantages that make it better for many types of tasks. It
doesn't have to be suitable for all documents to be interesting and
quite widely used. Precisely because it's trivially accessible in the
cloud, the phenomena that exists with Office's desktop competition --
the "I already have Office, why would I install another word processor
with fewer features?" thing -- largely doesn't exist with respect to
Google Docs. Because conceptually, you're not installing word another
processor. Many users might not even think about is as *using* another
word processor. Rather, you're creating a document in the cloud, that
has a set of editing tools associated with it.

This is a question of perception; you certainly *are* using a different word
processing, when you could be using Office Word. Maybe people don't think of
it that way, and maybe they do. But if they don't, perhaps some sort of
marketing campaign could make them see the light. :D

It's a conceptual difference. That's what I keep saying.

[snip]
Managed to track this down. WMP12 (which I'm sure will be extremely
common by the time HTML 5 is widely supported enough to be usable)
includes H.264 support out of the box. So we've got our common
codec right there.

We'll see. If it actually works like that, you get the thank
Microsoft for it, though.

I'm not sure why Microsoft should be uniquely thanked for grudgingly
implementing (several years late, as far as I'm concerned) an otherwise
widely adopted and highly successful open standard after making a go at
displacing it with their technology and largely failing.

Ah, yes. Because this is what Apple decided to implement, it's the One True
Way that everyone else is morally obliged to be compatible with. Somehow
Apple isn't obliged to be compatible with VC-1, no.

Well, I should have known you'd never thank MS for anything. :D

H.264 was created by a far more inclusive industry process than VC-1,
and seems to have the support of many more parties. VC-1 is essentially
a result of Microsoft being really bothered that the world was
standardizing on a codec Redmond had nothing to do with, and attempting
to "correct" the situation. I see no particular reason why the rest of
the world should encourage this.

--
"What the cynics fail to understand is that the ground has shifted beneath them
? that the stale political arguments that have consumed us for so long no longer
apply. The question we ask today is not whether our government is too big or too
small, but whether it works [...]" -- Barack Obama, January 20th, 2008
.