<br><br><div class="gmail_quote">On Thu, Jun 10, 2010 at 12:20 AM, Peter Beverloo <span dir="ltr"><<a href="mailto:peter@lvp-media.com">peter@lvp-media.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Wed, Jun 9, 2010 at 20:29, narendra sisodiya<br>
<<a href="mailto:narendra@narendrasisodiya.com">narendra@narendrasisodiya.com</a>> wrote:<br>
><br>
> Canvas API is just great and I love it, You will also love it , if not, just see Canvas demos - <a href="http://www.canvasdemos.com" target="_blank">http://www.canvasdemos.com</a><br>
><br>
> But we have potential danger to misuse it also for the sake of non-standards.<br>
><br>
> <prediction><br>
> 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 - <a href="http://twitter.com/jdowdell/statuses/14985295733" target="_blank">http://twitter.com/jdowdell/statuses/14985295733</a> , 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.<br>

> 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.<br>
>           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"<br>
><br>
> We urgently need HTML5 authoring tool. we urgently needs SVG authoring tools.<br>
><br>
><br>
> </prediction><br>
><br>
> I guess, with the advance of html5, Adobe has been working hard to run flash on canvas from server inorder to save its presence.<br>
><br>
><br>
> .<br>
> --<br>
> ┌─────────────────────────┐<br>
> │    Narendra Sisodiya<br>
> │    <a href="http://narendrasisodiya.com" target="_blank">http://narendrasisodiya.com</a><br>
> └─────────────────────────┘<br>
> Yet another HTML5 Developer.<br>
<br>
</div></div>Hello Narandra,<br>
<br>
Do you have any links or sources backing up that Adobe is working on<br>
the server-side? While your scenario certainly is possible, even with<br>
today's possibilities, I see a number of problems with it:<br>
<br></blockquote><div><br>No, i  do not have any info. I am independent developer who enjoy making predictions - <a href="http://blog.narendrasisodiya.com/2010/06/how-and-why-browser-share-ratio-will-be.html">http://blog.narendrasisodiya.com/2010/06/how-and-why-browser-share-ratio-will-be.html</a><br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
1) The number of simultaneous users in any web application will be<br>
severely limited by the available processing power of the server.<br>
Thinking of the current uses of Flash, a really large part of which<br>
are video players and games, it does not seem realistic. Extend this<br>
to Flash applications such as FarmVille on Facebook and server-side<br>
processing and rendering will be pretty close to impossible.<br> 
</blockquote><div><br>Yes, you are correct at this points,<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) How exactly is this different from normal webpages? A lot of<br>
websites use scripting languages as their back end, such as PHP,<br>
delivering a certain flexibility which is not directly visible to the<br>
user. The same thing can be applied to achieve creating personalized<br>
Application Cache Manifests.<br>
<br></blockquote><div><br>PHP script generate HTML code along with JavaScript. It make our task easy.  <br><br>But, Lets imagine <br>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.<br>
Let me explain this more<br><ul><li>Designer/Developer will use drag and drop based Toolkit which has altogether different higher level sytax which generate CANVAS based application.<br></li><li>Toolkit Or some JavaScript code will generate JavaScript code with all resource like image, htmlcode, source code and everything in application directory.</li>
<li>Toolkit will zip the whole application and finally designer/developer will get a <b>myfirstgame.wapp </b></li></ul>Now developer/designer need to write this much code<br><br><script src="./js/wapp-engine.js"></script><br>
<div class='wapp-application' data-src='./myfirstgame.wapp' width='600' height='800' /><br><br>This wapp-engine.js will be a wapp player which load <b>myfirstgame.wapp</b> using Ajax and unzip files. Create a dynamic canvas, and render the game in canvas area.<br>
<br>So we are using HTML5 canvas but what are we doing<br><ul><li>Fast and GUI based development tools with a non-standards/proprietary ToolKit for generating a .wapp files which can be distributed and developed easily</li>
<li>.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</li><li>Desktop based wapp player inorder to play downloded .wapp files.</li>
<li>Web will become a binary world.<br></li></ul>So, it is quite possible to introduce a new non-standard technology under the CANVAS API with Javascript unzip library.<br><br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On top of that, there are various Javascript obfuscators around which<br>
convert code to nearly unreadable pieces of text. While code<br>
formatting can be normalized using a range of tools, variables like<br>
"_" and "___" will be continue to be confusing nonetheless. </blockquote><div><br>Wow, I have not having this idea in my mind. thanks for the trick.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Such<br>
obfuscation is enough to stop 99% of the people from getting/copying<br>
the code, going through the trouble of continuous connections and<br>
server-side processing for that last percent seems unlikely.<br>
<br>
If any application is that critical, the author should consider<br>
limiting access to the application altogether.<br>
<br>
Regards,<br>
<font color="#888888">Peter<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>┌─────────────────────────┐<br>│    Narendra Sisodiya<br>│    <a href="http://narendrasisodiya.com">http://narendrasisodiya.com</a><br>└─────────────────────────┘<br>