[whatwg] Potential Danger with Canvas API in html5 #html5 #canvas

[Peter Beverloo]

On Wed, Jun 9, 2010 at 22:05, narendra sisodiya
<narendra at narendrasisodiya.com> wrote:
>
>
> On Thu, Jun 10, 2010 at 12:20 AM, Peter Beverloo <peter at lvp-media.com> wrote:
>>
>> On Wed, Jun 9, 2010 at 20:29, narendra sisodiya
>> <narendra at narendrasisodiya.com> wrote:
>> >
>> > Canvas API is just great and I love it, You will also love it , if not, just see Canvas demos - http://www.canvasdemos.com
>> >
>> > But we have potential danger to misuse it also for the sake of non-standards.
>> >
>> > <prediction>
>> > Case 1 - Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already  2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a Server Side HTML5 toolkit which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API.
>> > A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5.
>> >           So, This I do not like,,,--> ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5"
>> >
>> > We urgently need HTML5 authoring tool. we urgently needs SVG authoring tools.
>> >
>> >
>> > </prediction>
>> >
>> > I guess, with the advance of html5, Adobe has been working hard to run flash on canvas from server inorder to save its presence.
>> >
>> >
>> > .
>> > --
>> > ┌─────────────────────────┐
>> > │    Narendra Sisodiya
>> > │    http://narendrasisodiya.com
>> > └─────────────────────────┘
>> > Yet another HTML5 Developer.
>>
>> Hello Narandra,
>>
>> Do you have any links or sources backing up that Adobe is working on
>> the server-side? While your scenario certainly is possible, even with
>> today's possibilities, I see a number of problems with it:
>>
>
> No, i  do not have any info. I am independent developer who enjoy making predictions - http://blog.narendrasisodiya.com/2010/06/how-and-why-browser-share-ratio-will-be.html
>
>>
>> 1) The number of simultaneous users in any web application will be
>> severely limited by the available processing power of the server.
>> Thinking of the current uses of Flash, a really large part of which
>> are video players and games, it does not seem realistic. Extend this
>> to Flash applications such as FarmVille on Facebook and server-side
>> processing and rendering will be pretty close to impossible.
>>
>
> Yes, you are correct at this points,
>
>
>>
>> 2) How exactly is this different from normal webpages? A lot of
>> websites use scripting languages as their back end, such as PHP,
>> delivering a certain flexibility which is not directly visible to the
>> user. The same thing can be applied to achieve creating personalized
>> Application Cache Manifests.
>>
>
> PHP script generate HTML code along with JavaScript. It make our task easy.
>
> But, Lets imagine
> if we have a very good Tookkit which have everything for webdesign like buttions, menus, dropdown and final code renders everything in CANVAS. ToolKits may use altogether different higher level sytax to generate canvas based applications. further this toolkit has JavaScript unzip library. then you will be able to create a application in zipped format.
> Let me explain this more
>
> Designer/Developer will use drag and drop based Toolkit which has altogether different higher level sytax which generate CANVAS based application.
> Toolkit Or some JavaScript code will generate JavaScript code with all resource like image, htmlcode, source code and everything in application directory.
> Toolkit will zip the whole application and finally designer/developer will get a myfirstgame.wapp
>
> Now developer/designer need to write this much code
>
> <script src="./js/wapp-engine.js"></script>
> <div class='wapp-application' data-src='./myfirstgame.wapp' width='600' height='800' />
>
> This wapp-engine.js will be a wapp player which load myfirstgame.wapp using Ajax and unzip files. Create a dynamic canvas, and render the game in canvas area.
>
> So we are using HTML5 canvas but what are we doing
>
> Fast and GUI based development tools with a non-standards/proprietary ToolKit for generating a .wapp files which can be distributed and developed easily
> .wapp will be played in browser will be JS wapp player which render it inside CANVAS API with hiding images, text and everything under pixels which is the prime requirement of many website
> Desktop based wapp player inorder to play downloded .wapp files.
> Web will become a binary world.
>
> So, it is quite possible to introduce a new non-standard technology under the CANVAS API with Javascript unzip library.
>

It's a very interesting idea, proven by the fact that it partially has
been documented already in the W3C Widgets specification[1]. While the
Widgets currently mostly get used to distribute mobile applications,
which already has been implemented in Presto 2.5 and works on various
phones, it's uses are not limited to the mobile platform alone. The
specification could perfectly be used to create a Widget run-time in
Javascript, albeit in a very limited fashion as creating applications
on <canvas> is a lot harder than using raw HTML in, for example, an
iframe.

Also, keep in mind that the browser, specifically Javascript, needs to
know how to extract such a package (regardless whether it's a ZIP file
or another format) in order to gain access to it's contents. Any
developer who's quite savvy with Javascript will be able to add a few
lines of code that output the image to an <img> tag, instead of
rendering it on a canvas. With the upcoming live-editing Javascript
features in various browsers that won't be much of a problem.

Regards,
Peter Beverloo

[1] http://www.w3.org/TR/widgets/