[whatwg] about rich internat applications

I would argue that this is scope creep for this group.  While it might be 
admirable to have closed source web applications (I don't believe so), this 
working group seems to be taking existing HTML specifications, like CSS, 
and extending or strengthening them to support richer apps.  These existing 
apps are already plain, human-readable files; making them opposite would be 
a gargantuan effort.

Brad

At 06:28 PM 6/7/2004, Didier PH Martin wrote:
>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:36:21 UTC