[whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
peter at lvp-media.com
Wed Jun 9 11:50:17 PDT 2010
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.
> 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.
> 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.
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:
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.
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.
convert code to nearly unreadable pieces of text. While code
formatting can be normalized using a range of tools, variables like
"_" and "___" will be continue to be confusing nonetheless. Such
obfuscation is enough to stop 99% of the people from getting/copying
the code, going through the trouble of continuous connections and
server-side processing for that last percent seems unlikely.
If any application is that critical, the author should consider
limiting access to the application altogether.
More information about the whatwg