[whatwg] about rich internat applications

Hi Matthew

>     Well, if the components are not in a human readable format, they
> have to be compiled in a non-readable format in some way. If you're
> going to do that, what's the difference between that and a plug-in?

In a nutshell: the sandbox or the assurance that the component will not mess
up with my system outside of its sandbox. Even if the component is written
in a language like ECMAScript, it could be:

A) with its hidden source.
B) just in time compiled and locally running on a virtual machine.
C) just in time compiled and locally running on a virtual machine and stored
in a cache for the next time (hence saving the compiling time)
D) Its source open and compiled
E) Its source open and interpreted
F) Its source open, compiled and cached

I would favor standard languages recognized by some standardization
organization like ECMA, ISO, etc... ECMAScript is one of these, C# an other
one, C++ another one, sorry not Java.... 
Etc...

> Furthermore, how do you stop someone from taking the source code for an
> open source browser and modifying it to decompile the control? You're
> effectively reduced to using ActiveX controls to keep your code safe,
> which is what some people do already. Furthermore, people could still
> theoretically decompile the Windows ActiveX control you create.
> 
>     But wait!!! We can protect the ActiveX control with DRM!!!...
> 
>     See where I'm going with this?

Yes its possible to do that; some hackers can break almost anything. Most of
the developers don't.

> 
>  > Without any religious positions I think its better that we have
> > components available from a marketplace and some competition among the
> > vendors. If the code can behave in a sandbox with good security checks I
> > have no problems to not having access to the source code as long as I
> can
> > complete a project on time and with reasonable costs.
> 
>     You're right! Just look at the browser market and see how the closed
> source marketplace has--er--um--let me think of another example...
> 
>     Seriously, though, think of it this way. If the code is so valuable,
> what is it even doing on a client-side web app? And what client-side
> control/component is so innovative and ground-breaking that copyright is
> insufficient protection? Keep in mind that any hacker can crack a
> protection given enough time, so if a company were really so determined
> to reverse engineer a web component, they'd figure out a way.
> 
>     Bottom line: If you need to protect your code so badly that the
> threat of a copyright lawsuit is insufficient, you're better off just
> writing a native app.

You missed the point; the browser has also other advantages that stand alone
apps do not have. Freedom is to allow the choice of having a piece of code
closed or open. Reduced to a single option is reducing freedom. Let the
market place decide and provide them the choice. Obviously some browser
providers do not have unlimited resources and thus can only support a single
language (i.e. ECMAScript), so far so good, they can provide more freedom by
letting the authors the freedom of choice and the consumer the freedom of
choice of picking their component providers.

Cheers
Didier PH Martin


Cheers
Didier PH Martin

Received on Monday, 7 June 2004 18:28:15 UTC