Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Wed, Jun 9, 2010 at 22:05, narendra sisodiya wrote: > > > On Thu, Jun 10, 2010 at 12:20 AM, Peter Beverloo wrote: >> >> On Wed, Jun 9, 2010 at 20:29, narendra sisodiya >> 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. >> > >> > >> > 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. >> > >> > >> > >> > >> > 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 > > > 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 r
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Thu, Jun 10, 2010 at 12:20 AM, Peter Beverloo wrote: > On Wed, Jun 9, 2010 at 20:29, narendra sisodiya > 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. > > > > > > 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. > > > > > > > > > > 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 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 un
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Wed, Jun 9, 2010 at 3:26 PM, narendra sisodiya wrote: > Yes, sure, I love to advocate adobe/similarcompany and modify my video - > http://tinyvid.tv/show/2dz18ka146nfz , Provided they should do it in Client > side so source can be seen. Providing a server side or similar rendering > system which use 'Canvas' for displaying everything inside canvas from > server side is as bad as flash player/plugin.Web may be hidden again under > pixels. It's not as bad. It will work equally on all browsers and all platforms, and several parties will get to compete on some key aspects of the implementation (such as the speed and stability of the underlying JavaScript). It's not much different from any website using closed-source server-side code. > We can't stop anyone. Advocate SVG and making SVG-animation support with SVG > animation authoring tools is a good way to reduce 'server side canvas > rendering'. If you don't have spec changes to propose, this is probably the wrong list.
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Thu, Jun 10, 2010 at 12:24 AM, Aryeh Gregor > wrote: > On Wed, Jun 9, 2010 at 2:29 PM, narendra sisodiya > wrote: > > 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" > > The goal of HTML5 is that all browsers and platforms should be able to > display all web pages, without dependence on any particular software > vendor. If a company like Adobe writes a framework using > cross-browser, cross-platform, openly specified APIs, we're in a far > better situation than now. It would really be no different from > jQuery. > > Yes, sure, I love to advocate adobe/similarcompany and modify my video - http://tinyvid.tv/show/2dz18ka146nfz , Provided they should do it in Client side so source can be seen.* Providing a server side or similar rendering system which use 'Canvas' for displaying everything inside canvas from server side is as bad as flash player/plugin.Web may be hidden again under pixels.* > Furthermore, it's not *possible* to prevent anyone from writing > toolkits that use HTML5 features. Or do you have any suggestions to > stop it? > We can't stop anyone. Advocate SVG and making SVG-animation support with SVG animation authoring tools is a good way to reduce 'server side canvas rendering'. -- ┌─┐ │Narendra Sisodiya │http://narendrasisodiya.com └─┘
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Wed, Jun 9, 2010 at 2:29 PM, narendra sisodiya wrote: > 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" The goal of HTML5 is that all browsers and platforms should be able to display all web pages, without dependence on any particular software vendor. If a company like Adobe writes a framework using cross-browser, cross-platform, openly specified APIs, we're in a far better situation than now. It would really be no different from jQuery. Furthermore, it's not *possible* to prevent anyone from writing toolkits that use HTML5 features. Or do you have any suggestions to stop it?
Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Wed, Jun 9, 2010 at 20:29, narendra sisodiya 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. > > > 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. > > > > > 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: 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. On top of that, there are various Javascript obfuscators around which 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. Regards, Peter
