From: Juraci Krohling Costa Date: 2005-04-14T06:06:46+09:00 Subject: Re: What's beyond Rails? ------=_Part_4436_21895812.1113426385196 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline *brain search: web os* 1 Result found: myWebOs.com Does somebody remembers something about mywebos.com ? I= t=20 was a project to develop an "entire" OS web-based. Obviously, you still=20 needs a "real OS" to boot, but everything was on myWebOs: spreasheets,=20 "word" documents, email client, etc etc etc. I don't know when exactly they= =20 were gone, and where exactly they stopped, but that was a great idea. Some URL's that I found on google, to make sure I'm not nuts =3D) http://www.xent.com/nov99/0465.html http://www.pcworld.com/news/article/0,aid,14077,00.asp regards, juca On 4/13/05, Matt Pelletier wrote: >=20 > The underlying issue is that HTTP was never designed to do what it is > being used to do. Much like HTML is now doing things it was never > designed to do. Designers took HTML and starting using it for layouts, > like they were used to with Desktop publishing tools. After the mess of > nested tables and FONT tags, CSS came around and became an elegant > solution. HTTP is being asked to pretend it's not stateless. Fortunately > people have spent a lot of time thinking about this. Unfortunately not > all of the ideas are good. >=20 > 1. Post-backs > I have wasted plenty of time trying to work around ASP.NET's=20 > postback > architecture. For simple apps it indeed will ostensibly work like a > WinForm. For anything moderately complex, you can get into a mess of > issues when designing controls and components. Blech. I think the entire > premise of postbacks is flawed (hopefully I'm not naively soured just by > MS's implementation). Rather, relying on a postback paradigm to mimic > statefulness is flawed. >=20 > 2. Ajax > Ah, asynchronous requests, in-page, you say? Beautiful. No more posting > back (at least not continuously)? Great. I can see the faces of a > thousand web developers as they anxiously got their invite to gmail > (back before they were being given away in wheelbarrows), and watched in > awe as the 'view source' command produced not much more than a gigantic > javascript library. We've since seen other things like Google maps, and > Tada list, and so on. Beyond giant companies dedicating teams of people > for specific apps like Google does, I expect RoR to be the 'platform' > pushing the envelope with this. >=20 > Unfortunately, Javascript is not going to be doing Photoshop-like work > anytime soon. >=20 > 3. RIA > Macromedia has been pushing what it calls 'Rich Internet Applications'. > The idea is simple. 99% of browsers have Flash installed, with PLENTY of > spare CPU cycles to do the graphics work. Flash can make asynchronous > calls like Ajax's HTTPXmlRequest. >=20 > Recent versions of Flash (MX, MX 2004) have moved in the direction of > App development, with form controls, theming, and more powerful > ActionScript. You can either write directly in Actionscript, or you can > also use it's developer IDE Flex to write in an XML spec Macromedia > developed (cleverly dubbed MXML). The RIA platform is setup like so > (correct me if I'm wrong here): You get Flex Server running, and develop > RIAs using MXML (MacromediaXML), and Flex server turns them into Flash > forms. Neat. It's still maturing, but I think ultimately it's quite > promising. >=20 > Macromedia even has a desktop wrapper for flash RIA apps called Central. > You can download modules like a weather checker, etc. It sort of has an > OS X Expose widget look about it. It's a resource pig and it's slow, but > again, so was (er.. is) Java. That's what happens when you build your > own graphics layer. >=20 > 4. Dumb Terminals / Thin Clients > This one has been tried again and again and there's no great solution. > Microsoft released a version of Windows for thin clients. IBM dumped a > ton of money into this. Ultimately people don't want to have just thin > clients. They want a hard drive, music, etc. Google's ability to make > cheap server farms is just as important as their ability to make > searches effective. I wouldn't rule them out from trying anything right > now, but I don't think they're after desktop software like photoshop. > Their position seems to be that the overall paradigm has changed from > desktop-run to Internet run. Just read Paul Graham's 'The Other Road > Ahead'). >=20 > http://www.paulgraham.com/road.html >=20 > So what comes after? I don't know. HTTP is an inherently flawed way to > use the Internet if you want desktop-like apps like photoshop, but the > web has such saturation that people have and will continue to try to > make it work. >=20 >=20 > James Toomey wrote: > > Somewhat off-topic rant: This isn't so much a dig at Rails but a > > critique of HTML in general. I've done web development with PHP, > > ColdFusion, and ASP, and being able to use Ruby in doing so (especially > > with Rails' well-designed database interactivity) is certainly a > > welcome change. However, the general model is still the same, in terms > > of using code to write out HTML to an essentially-static page. The HTML > > interface is still such a far cry from the things you can do with a > > rich client. For ordering airline tickets on Travelocity or books on > > Amazon, the web works great, but imagine trying to emulate Adobe > > Photoshop via a web browser, or a spreadsheet like Excel. > > It seems to me that there needs to be a next-generation of HTML that > > enables web apps to truly be like rich client apps, and > > I don't think the solution needs to be a faster connection that sucks > > down the entire application in the form of massive Java applets every > > time I want to use the program. Perhaps the solution does need to be a > > "computer" that's designed from the ground up as a web-enabled dumb > > terminal, but that has forms and controls optimized so that they > > require minimal data inflow to tell them what to do. > > To me, this would make the web incredibly more useful (and would put > > serious potential into the claim that Google wants to become a web > > operating system). If I've purchased Adobe Photoshop (or rented it, as > > I'm sure will be the more likely model), instead of loading it on every > > computer I use, why can't I get to Photoshop at any computer in the > > world merely by logging into my personal website and getting access to > > every software program I own or am renting? Why would it need to be > > reloaded at every computer? This is particularly annoying when you're > > visiting a friend in another city for a weekend, and jump onto his > > computer to check email or show him how to do something useful, and > > think, "I wish I had App X loaded on here right now." > > I was disappointed to see Google Suggest being touted as innovative; it > > seems to indicate that Google's going to stay within the existing web > > realm and not try anything really new (as I read on the web somewhere, > > "for a web app, Google Suggest is neat; for a desktop app, it's so > > 1995"). For all of Google's deep pockets and reputation as innovative, > > I expected to see them partner up with a hardware manufacturer and try > > something dramatically different. > > > > > > > > >=20 >=20 --=20 juraci krohling costa http://jkcosta.info ------=_Part_4436_21895812.1113426385196--