Chromeless Supplants Mozilla's Prism Project 111
mikejuk writes "Mozilla Labs has dumped its Prism project, that was intended to bring web applications to the desktop, in favor of a revamped and repurposed Chromeless, a way of building experimental web browsers, to provide yet another way to create a desktop app using web technologies."
Single point of failure development (Score:5, Insightful)
Why does everything have to be built on desktop apps dependent on the web or web browsers?
We've been doing desktops since dirt, and have it pretty well understood, reasonably well standardized
across multiple operating systems. The building blocks are well understood, highly developed and
well documented.
So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the
web, and why does it seem everyone wants to turn the browser into the building block upon
which everything else depends?
And don't get me started on clouds!!!
What do we gain besides a huge dependence on things outside of our immediate control.
Did events in Egypt not teach us anything about putting every thing on the web and in
the cloud?
Re:Single point of failure development (Score:5, Insightful)
But I agree, sticking everything in the stupid browser is annoyingly limited. I can't imagine Photoshop or Maya being browser based. Hell, their browser based help systems don't even work well and that's just linked text - something a browser ought to be good at.
But the vast majority of users don't go past simple stuff - where a browser UI isn't bad. And Bog knows we ought to put everything on the network so that the poor little user can't screw things up.
That's our job.
Re: (Score:1)
> Browsers are lightweight, 'easy' to program. Cheap. More or less OS independent.
So, that's the technology argument. It's kind of weak in the sense that it leaves room for someone to say "hey, but desktop software can do the same thing, better," which is probably true. It's a fine enough position for a tech-y to take.
But consider that most people in business environments don't have access to install applications on their machines. This includes management and pretty much everyone not in IT. Therefore,
Re: (Score:2)
Once again, it is Microsoft's fault.
Re: (Score:2)
and open office users having their own mess.
Once again, it is Microsoft's fault.
A problem in Open Office is a fault of Microsoft? How?
Re: (Score:2)
Re: (Score:2)
A problem in Open Office is a fault of Microsoft? How?
Because Microsoft too long to publish specifications for its Office document formats.
Re: (Score:2)
A big part of this was the long-time lack of local "sandboxed" applications on Windows systems. If it had been easy for people to install lightweight software on their desktop in such a way that IT wasn't threatened by its very existence, we might never have reached this point.
Then again, one of the big "security features" of these apps is the idea that internet access is far less dangerous (when granted to an untrusted application) than local network access. On the desktop, we've been pushing the inverse
Re: (Score:2)
The web became the new visual basic, mostly due to the fact that it took some small amount of skill to drag and drop form elements onto a window in a way that doesn't fuck up if the user's resolution is not exactly like yours, while the html browser will reflow the text so it may still look like shit but at least the form will scroll if it doesn't fit, instead of putting the buttons off the bottom of an unresizable modal dialog that windows won't let you drag up off the top of the screen so you can see them
Re: (Score:2)
I can't imagine Photoshop or Maya being browser based.
There already are some photo-editing solutions, and WebGL is on the way.
Hell, their browser based help systems don't even work well...
That's not the fault of the browser -- there are plenty of browser-based help systems which work so much better than "on-line" help systems that I wonder why anyone does it that way. (Read "on-line" as "computerized help system, but still locally" -- the term probably predates popular use of the Internet.)
Local browser-based help (Score:2)
there are plenty of browser-based help systems which work so much better than "on-line" (computerized, local) help systems that I wonder why anyone does it that way.
Probably because browser-based help systems either A. lack search (if they operate through the file: scheme), B. require a web server running on localhost (for which a firewall presents a scary warning), or C. require a $60/mo subscription to mobile broadband if used on a laptop on a bus.
Re: (Score:2)
C is becoming less and less relevant. Not only are mobile subscriptions prevalent, but we have wifi everywhere. It's on airplanes.
I find myself wondering what the overlap is between those who are using a laptop on a bus and those who know how to spider a web-based help system with 'wget -r'.
Re: (Score:2)
we have wifi everywhere. It's on airplanes.
And on airplanes, it's priced as a luxury service. It isn't on Citilink buses (Fort Wayne, Indiana) or in Glenbrook Square Shopping Center (Fort Wayne, Indiana) at all; instead, one must either pay $720 per year for mobile broadband or do without.
I find myself wondering what the overlap is between those who are using a laptop on a bus and those who know how to spider a web-based help system with 'wget -r'.
For one thing, robots.txt. A lot of sites aren't designed to be spidered; they might be database driven, with different sets of CGI parameters showing essentially the same data. They might allow only a specified number of page views per hour to counter bandwidth ab
Re: (Score:2)
If you can't imagine Photoshop being browser based then I suggest you visit pixlr [pixlr.com]
Re: (Score:1)
No need to imagine a browser based Photoshop, go see it at pixlr [pixlr.com]
Re: (Score:1)
Re: (Score:2)
Picnik (Score:2)
You may think "photoshop can't be browser based", but you may be surprised. As an example, my wife recently directed all her desktop photo apps and only uses picnik.com. Granted, it is certainly not photoshop - but I can see it eventually getting there, maybe as early as a year or two.
Really, with Canvas and WebGL, there is nothing browsers can't do today that a desktop app can do.
Re: (Score:1)
The web browser is a fine, robust piece of software, but its sensibility is extremely outdated: when is the last time any of us actually "browsed" the web, outside of something like stumbleupon? I use my browser to read newsfeeds, check email, and to look things up
Re: (Score:2)
Not only this, but it's not like desktop applications can't call web services or something. Just set up your desktop apps to call web services.
If the mobile internet has taught us anything, it's that we should be trying to cram everything into the browser, especially where it doesn't belong.
Re:Single point of failure development (Score:4, Interesting)
The issue is not that desktop applications can't access a network service - indeed, an increasing majority of desktop programs appear to be doing so - but that web "apps" provide a certain advantage from a development perspective. It's the thick-client-vs-thin-client for the GUI world - a web "app" gives you all the following basically for free:
- cross-platform - get the browser independence right, and you don't have to account for the vagaries of Windows, Mac and Linux.
- globally accessible - log in anywhere with a "terminal" in the form of a browser window (see: e-mail)
- lightweight versioning and updating - no need to roll out updates to each and every user, just update the pages served (see: Facebook)
- familiarity - everyone understands the language of hyperlinks, or can be taught to very quickly.
Some apps will not migrate to the web for some time yet - games, system and basic utilities like text editors, and heavyweight programs that need serious access to hardware. "Productivity" stuff can move over pretty damn easily.
Re: (Score:2)
- cross-platform - get the browser independence right, and you don't have to account for the vagaries of Windows, Mac and Linux.
That is exactly the same. Browser independence is probably as hard, if not harder then OS independence. Besides, if you program to a good toolkit designed for the purpose, like QT, then you get platform independence.
- globally accessible - log in anywhere with a "terminal" in the form of a browser window (see: e-mail)
Moderately so. At the moment, many advanced features will only
Re: (Score:1)
Re: (Score:2)
Give up on canvas/pixel models and start using SVG elements(Ignore IE)
Ignoring nearly half your market is business suicide. You can't just direct users to install a browser because the user isn't necessarily an administrator.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
making applications web dependent is another way to invade peoples privacy
Sorry your data was stored on a system that also hosted data of an accused criminal. The system has been confiscated by the FBI so your data is gone.
Whoops,
Cloud Data Provider.
Re:Single point of failure development (Score:5, Insightful)
why does it seem as if everybody wants to make us dependent on a 24/7 connection to the web
How else do I say it: Because it's *easier*! Rumors that desktop application development is "well understood", well documented, and highly developed, are incorrect.
I'm an application developer, supporting both client-side and web-based models, and it's much, much easier to support a web-based model than a client-side model. With a web-based model, you can almost always replicate bugs reported by end users without much fuss. You hold the cards, so you can recreate problem scenarios and not have to bother the client with all that.
But, with client-side development, you run into situations where (I shit you not!) a combination of an antivirus package and MS Office (no, I'm NOT KIDDING) causes your application to mysteriously stop working. You can't recreate it, despite having a test machine with the same version of windows, similar hardware, etc. The only way to reproduce the problem is on the client's computer, and they are behind a firewall that prevents any remote desktop software from working.
Have you ever travelled 600 miles in order to discover that the problem was their antivirus in combination with a dumb file association with MS Office?
But when it's web-based, the problem is significantly easier to manage. Browsers are much more standardized than desktops. Javascript runs pretty much the same on 32 bit systems as 64 bit systems, PPC, ARM, or i386, Windows, Macintosh, Linux, or iOS, regardless of firewalls, antivirus, or whatever.
And to be truthful, end users are often unable to grasp basic things like saving files, let alone backing them up. But when it's web-based, I can provide a very, VERY strong assurance that backups have occurred within the last 24 hours, 365 days per year!
See the difference yet?
Re:Single point of failure development (Score:5, Insightful)
All the browser based applications I've ever used suck compared to something similar written in c or c++ (maybe a reflection of how accessible it is to crappy devs and not of the concept). But really I've not run into many of those, there's just not that much need for actual applications in the browser.
What I do see more and more every week are "web apps" (hear me vocalize the quotes) that really need to be web pages. It's as if people can't put up a paragraph of text with a photo unless there's 4 layers of abstraction and 3 jquery scripts to help them.
Re: (Score:2)
you're partly right - webapps are written in script because its easy to do so, not because it makes the best apps. That encourages the crappy devs, but they've been courted by language designers for a while now - .net, java all designed to 'make programming easier', not better.
That evolved the browser/web ecosystem to be a kind of 'lowest common denominator'. A bit like Java's JVM being a platform you develop on instead of developing native apps.
Web is a similar abstraction. We can write thick client, 3 tie
Re:Single point of failure development (Score:4, Insightful)
why does it seem as if everybody wants to make us dependent on a 24/7 connection to the web
How else do I say it: Because it's *easier*! Rumors that desktop application development is "well understood", well documented, and highly developed, are incorrect.
See the difference yet?
Rumors that Web interface is easy to build are grossly exaggerated.
If they are without JavaScript, you are stuck within the "power of expression" of HTML. If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare (everything is Runtime and interpreted, no strong typing, a very loose "Object Oriented" programming paradigm, managing the "context/status of the application" may - and will - create troubles due to the lack of concurrent programming, almost everything is asynchronous, etc).
The best combination for crafting an application I encountered: sandboxed but still rich/smart clients, potentially written as an "update-able plugin". SWT/Eclipse Framework is the first example to spring in mind - many others may exist - : write your application as an Eclipse Plugin and use Eclipse Framework the way an "Web application uses a browser".
Re:Single point of failure development (Score:4, Interesting)
If they are without JavaScript, you are stuck within the "power of expression" of HTML.
If they are without JavaScript, they're probably not the target market anyway. But suggesting that this limits you to HTML... really? I guess server side code doesn't exist?
If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare...
Having done web development, frankly, no it doesn't, not if you know what you're doing.
everything is Runtime and interpreted, no strong typing,
Which means the application itself was much, much quicker to develop and easier to maintain. Also, I have to say, I've never once been saved by the type system that I can remember -- the kinds of bugs I run into, even if they're runtime, never arise because I was using an object of the wrong type. Not once.
a very loose "Object Oriented" programming paradigm,
Erm... What's "loose" about prototypal inheritance? What makes classical inheritance better?
No offense, but are you sure you actually understand the JavaScript object model? It may be that you understand it and dislike it, and prefer other models instead -- but most people who hate JavaScript for not being "OO enough", in my experience, don't really understand JavaScript at all.
managing the "context/status of the application" may - and will - create troubles due to the lack of concurrent programming,
Also means we don't need locking. That's right, web apps don't deadlock.
almost everything is asynchronous,
You say that like it's a bad thing.
Re: (Score:2)
I'm a web developer too, and most of my JS troubles come from different browser behaviours.
I mean, for the average web app there's no difference if you're using something like jQuery, but even then, every so often, IE throws up an issue (But jQuery's quite good at making it play along, or degrade nicely).
Complicated web apps are harder to do properly on all browsers due to the way sandboxing works over the different browsers. There's no use testing some apps locally as some browsers will refuse to do AJAX c
Re: (Score:2)
If they are without JavaScript, you are stuck within the "power of expression" of HTML.
If they are without JavaScript, they're probably not the target market anyway. But suggesting that this limits you to HTML... really? I guess server side code doesn't exist?
Lapse of mouth, my apologies (the server side logic is implicitly understood as present)
If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare...
Having done web development, frankly, no it doesn't, not if you know what you're doing.
Yeap, this is why many Web2.0 interfaces look different enough in different browsers?
everything is Runtime and interpreted, no strong typing,
Which means the application itself was much, much quicker to develop and easier to maintain. Also, I have to say, I've never once been saved by the type system that I can remember -- the kinds of bugs I run into, even if they're runtime, never arise because I was using an object of the wrong type. Not once.
Yes. yes, I believe you... you are a very accurate typer and never mis-type a variable name when using it.
a very loose "Object Oriented" programming paradigm,
Erm... What's "loose" about prototypal inheritance? What makes classical inheritance better?
No offense,
None taken. Method overriding is awkward and method overloading is missing. Because of the missing strong-typing among others.
and but are you sure you actually understand the JavaScript object model?
Yes I do.
managing the "context/status of the application" may - and will - create troubles due to the lack of concurrent programming,
Also means we don't need locking. That's right, web apps don't deadlock.
No, indeed no deadlock, they simply suffer from race-conditions. Awfully.
For instance, loading the
Re: (Score:2)
If they are without JavaScript, you are stuck within the "power of expression" of HTML.
If they are without JavaScript, they're probably not the target market anyway. But suggesting that this limits you to HTML... really? I guess server side code doesn't exist?
Lapse of mouth, my apologies (the server side logic is implicitly understood as present)
Then what's your point? If the problem is that raw HTML isn't fun to write, I always work with at least a tool like Haml, and often plenty of server-side libraries which handle HTML generation.
If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare...
Having done web development, frankly, no it doesn't, not if you know what you're doing.
Yeap, this is why many Web2.0 interfaces look different enough in different browsers?
I wouldn't say "looking different" is necessarily a problem for all apps, and there certainly is significant work needed to support multiple browsers -- though certainly no more than it takes to deal with multiple OSes, or even just multiple weird setups on a single OS, if you really want to go back to desktop apps. (
Don't be so hard on him (Score:1)
Re: (Score:2)
He was just saying that web development is hard,
...while replying to a post which said it's easier than the alternative -- which was replying to a post which said we should go back to desktop apps for everything.
indeed it is with it's mishmash of HTML, JavaScript, CSS, server-side languages, asynchronicity, multiple browsers to support.
Contrast that with your options with a desktop app. Any little quirk in what versions of software the user has installed, or how they're configured, or how they talk to each other. As mcrbids said:
...combination of an antivirus package and MS Office (no, I'm NOT KIDDING) causes your application to mysteriously stop working.
And that's assuming you're only doing Windows. Now imagine you want to do other OSes -- Mac, Linux, etc. Now you've finally got all that handled, mayb
Re: (Score:2)
I was about to come in here and say pretty much what you said, but you'd already said it, and Slashdot doesn't let you moderate in any forum that you've replied into.
So... well said!
Re: (Score:2)
And can you "keep the flow going while resources are still loading" more easily with a synchronous model? Especially with some sort of threading model? That's where I'm confused -- I don't mean that async is easy, but it certainly seems easier than the alternatives.
Re: (Score:2)
If they are "powered" by JavaScript, the cross-browser compatibility and debugging/tracing on "what the hell is wrong" becomes quickly a nightmare (everything is Runtime and interpreted, no strong typing, a very loose "Object Oriented" programming paradigm, managing the "context/status of the application" may - and will - create troubles due to the lack of concurrent programming, almost everything is asynchronous, etc).
There's also GWT.
Re: (Score:2)
Re: (Score:2)
Let me ask yo
Fishing expedition (Score:2)
Re: (Score:2)
With a desktop application stored on the local network, you would first have to know something of interest EXISTS before you could go on a fishing expedition. If it's over a web app, mere traffic analysis may be sufficient to reveal something of interest.
Re: (Score:2)
Re: (Score:2)
And don't get me started on clouds!!! [ramblingfish.com]
FTFY
Re: (Score:2)
The idea of Prism has it's place. Imagine for example a Prism set up for Internet banking. Separate settings, tighter security, no risk of infecting the browser on some random web site, ...
Re:Single point of failure development (Score:5, Interesting)
That's the way someone who understands computers thinks. We are not the majority of people who use computers anymore. The majority of people do NOT understand the way computers work, they just happily sign on to Facebook or their Email when they want to. The idea of being able to go to their friends house and access all their stuff there seems like something out of Sci-Fi to them. It's super cool, and nothing but convenient. I mean, why WOULDN'T you want to be able to do that?
Things like privacy issues aren't really a concern to them either. You ever tried to tell someone about the way Facebook operates, and had them say they don't care about any of that? Happens to me all the time. Also, as a general rule, a lot of people (especially in North America) see what is happening in Egypt, and say to themselves "But that could never happen here."
Finally, in closing, a lot of people do not WANT things in their immediate control. Having all your data on your computer means that it could break, or could get a virus, and then it's in danger of being lost unless Geek Squad can fix it. Many would rather trust it to Google than to themselves. Having worked previously in Geek Squad many moons ago, I have to say, for some of them, trusting their data to anyone but themselves was the wise thing to do.
Re: (Score:2)
Why does everything have to be built on desktop apps dependent on the web or web browsers?
On the "web browser" front, what's your problem here? Do you have a pressing need to make an app work on a computer which has no web browser?
We've been doing desktops since dirt,
And we did shared servers long before that -- used to be a computer wasn't something everyone had on their desk.
The building blocks are well understood, highly developed and well documented.
The same can be said of the Web.
So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the
web,
Ok, how the hell did you get modded up with FUD like that? This is exactly the kind of FUD people used to spread about Linux -- untrue and you know it, so why say it?
Web apps can and do have offline modes, for the cases where i
Re: (Score:2)
"Making something a web service means if it's at all decent, it's also now OS-independent, which means I've now lost the single-point-of-failure of Microsoft."
Or linux, or OSX, or bsd, etc. You've also gained the multiple points of failure of web services with their variable ethics for securing personal information, bigger target for data sellouts/hacking(facebook), ISP data rate games, connection stability, browser compatibilities, etc.
When it's your machine you control what's going on. You
Re: (Score:2)
When it's your machine you control what's going on. You can always switch OSes
Not if the machine verifies the machine's manufacturer's digital signature on each stage of the bootloader and kernel.
Re: (Score:2)
You've also gained the multiple points of failure of web services with their variable ethics...
How is this different than software developers with variable ethics? The only difference is where the data is stored, and since a web application can operate entirely offline, including offline storage, that's a design detail.
bigger target for data sellouts/hacking(facebook),
I'm not really sure what Facebook has to do with this, especially as there are plenty of non-web applications for talking to Facebook -- so again we see that taking it off the web doesn't necessarily help. In this case, it's not that Facebook is web-based, but the fundamental nature of
Intermittent connection to the Internet (Score:2)
Do you have a pressing need to make an app work on a computer which has no web browser?
No, but I have a pressing need to make an application work on a computer which has a web browser but an intermittent connection to the Internet. When the connection is down, such as if the user is a passenger in a vehicle, the browser can view only manually downloaded files, the 5 MB of cached application files, and the 5 MB of data in localStorage.
Re: (Score:3)
So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the web, and why does it seem everyone wants to turn the browser into the building block upon which everything else depends?
Because it's a potentially endless source of revenue. It's really that simple.
Re: (Score:2)
As far as i am concerned being Operating System agnostic is the key.
There will be a time when web based applications surpass their desktop counterparts. (There would be those who would argue in some areas it already has).
Being able to access my email on any device or operating system through Gmail (or whatever your poison) by doing nothing more than supplying credentials, is something that is a very good example and one which most of us couldnt live without. Particularly here on slashdot where most of us ar
Re: (Score:2)
Cause otherwise, people develop little apps.
App to read site X. App to read site Z.
We lose in genericity (yeah i invent words today), standardization, etc.
This is very seriously happening on smartphones and that will spread eventually. The problem is that those apps are more buggy, not free, not compatible, etc - basically destroying everything the current browser stands for.
By making a simple version of the same browser that give you a feeling of these "little apps" they probably hope to keep all the advan
Free as in speech or beer? (Score:2)
The problem is that those apps are more buggy, not free, not compatible, etc
Did you mean "free" as in free speech or free beer? If free speech, then the works on the site probably aren't free [freedomdefined.org] either. If free beer, then what's the big difference between having to pay for a specific app to read a site and having to pay for an account to read a site through standard web protocol?
No Internet needed (Score:2)
This is just based on webtechnology, you do NOT need a working internet connection to use it.
Even then, HTML5 has support for offline use, for when your connection is down.
Size limits (Score:2)
Even then, HTML5 has support for offline use, for when your connection is down.
Which works well unless A. Internet Explorer is the only browser installed and your user is not an administrator, or B. you run into size limits enforced by user agents: 5 MB for files linked from CACHE MANIFEST and 5 MB for localStorage.
Re: (Score:2)
Because, it is very difficult to go to a location and install a desktop application. I was there and did it. Thank you very much.
Then the PC breaks down and I had to drive to install again. DLL error - drive again. On 100 PCs it is OK, on 1 - an error. Then on thin clients I had to spend 4 hours to install one desktop application, because it was missing some file in the OS.
Nowadays, I do not care what OS or what PC is on a location. Browser, htpps connection, login, password, that is it. Change complicated
Re: (Score:2)
A spare Internet connection makes the Internet access practically uninterpretable. Egypt is rather an exception, but still one could use a satellite dish link, like they use nowadays on the ships.
Re: (Score:2)
Re: (Score:3)
We've been doing desktops since dirt, and have it pretty well understood, reasonably well standardized
across multiple operating systems. The building blocks are well understood, highly developed and
well documented.
that's exactly the problem. multiple. operating. systems. making a desktop app that runs on all of them is a pain in the ass, an for commercial developers, expensive. no wonder that the majority of multi-plataform apps are opensource. now, developing for web, finally bring the dream of "write once, run everywhere", something that java promissed but failed to deliver in large scale.
So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the
web
HTML5 can store data locally, i guess this includes the applications files, so you can still use them while offline.
And don't get me started on clouds!!!
What do we gain besides a huge dependence on things outside of our immediate control.
Did events in Egypt not teach us anything about putting every thing on the web and in
the cloud?
most non-tec
Re: (Score:2)
HTML5 can store data locally, i guess this includes the applications files, so you can still use them while offline.
So what should your application do when it runs up against A. the user agent's limit of 5 MB for offline application files linked from the CACHE MANIFEST, B. the user agent's limit of 5 MB for data in localStorage, or C. the user agent's lack of methods first introduced in Firefox 4 [mozilla.org] for file input objects (<input type="file">)?
Re: (Score:2)
Why does everything have to be built on desktop apps dependent on the web or web browsers?
We've been doing desktops since dirt, and have it pretty well understood, reasonably well standardized across multiple operating systems. The building blocks are well understood, highly developed and well documented.
Mozilla makes web browsers. They're trying to create a dependence on their product like Microsoft did with windows years ago.
So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the web, and why does it seem everyone wants to turn the browser into the building block upon which everything else depends?
And don't get me started on clouds!!!
What do we gain besides a huge dependence on things outside of our immediate control.
Did events in Egypt not teach us anything about putting every thing on the web and in the cloud?
It's not what WE gain, it's what corporations gain in the form of DRM, and tracking your online activities so they can make more money. There's nothing magical or new about any of this, companies will do what's in their best interest regardless of what's in the customer's best interest. Sometimes those two interests cross paths, and sometimes they don't. There's way too many unedu
Re: (Score:2)
So why does it seem as if everybody wants to make us dependent on a 24/7 connection to the
web
Web apps don't necessarily depend on a 24/7 connection to the web [whatwg.org].
CACHE MANIFEST and quotas (Score:2)
Re: (Score:1)
The technology is not quite there to build browser-based apps that can adequately replace desktop apps. But that's the whole point of the Chromeless project as I understand it.
I have, in the past year, switched from a desktop email client to Gmail. It is tantalizingly close to being a perfect setup. There are just a few things that don't quite work as they should (better desktop notifications, opening links in my default browser, for instance). If those things were fixed it would be great. Meanwhile, I c
Re: (Score:1)
What do we gain besides a huge dependence on things outside of our immediate control.
Data concurrency.
Nice Idea (Score:2)
Re: (Score:2)
The fundamental problem with prism is that it wanted to open links in itself. So if you're using say Facebook as a prism app then you want external links to open in your actual system web browser, and they don't, they open in prism. And all your prism windows associated with a single --app flag will open with the same (lack of) decoration. So the prism paradigm is broken if you use anything with external links. If it doesn't have external links then it's fucking stupid for it to be a web-based application a
Mozilla has too much on their plate. (Score:1)
Seriously, fix Firefox 4.0 first then play with all these hobby projects.
A positive step forward. (Score:2)
Re: (Score:2)
Going a step further, using Chromeless is going to make more people look at XULRunner, the program which fires both Firefox as well as Thunderbird.
Great! Because the only thing better than software that doesn't integrate well with one platform is software that doesn't integrate well with *any* platform!
Re: (Score:2)
I used Prism to provide links for my kids to their favorite games as icons on the desktop. I loved the ability to hide the GUI features that would just distract them. I will miss this software. it was very useful.
Makes a shortcut that runs 'chrome --app="http://url"' (or chromium-browser, or whatever your chrome executable is)
I'm going to ask this here (Score:1)
Whyt he fuck does the new system, in your "Comments" section for your account, take you to the parent conversation when you click on it instead of your fucking post? It's very stupid, is this some new "default" functionality I need to turn off? Seriously, why would I want to dig through a conversation tree looking for _my_ post, instead of being taken right to it?
Re: (Score:2)
"The Cloud" is mainframe madness on a large scale. Mainframes were killed off years ago for many reasons. Single point of failure: internet is down, you, your business is down. No thanks.
To which I'd add: internet is down, can't even play them games offline. No thanks.
Re: (Score:2)
Power is down, you, your business is down. No thanks, we'll stick to paper.
Really? That's the best you can come up with? They have internet on airplanes now. It's getting harder and harder to find a place without Internet. Internet's down at work? Grab some laptops and head over to your local Starbucks.
Oh, and I hate to be the bearer of bad news, but much as I wish they'd die, mainframes are still going strong, and IBM is even selling new ones. If you want job security, become a mainframe programmer.
Re: (Score:2)
http://www.w3.org/TR/html5/offline.html [w3.org]
http://diveintohtml5.org/offline.html [diveintohtml5.org]
Agree! (Score:1)
Re: (Score:1)
Re:Chromeless...Chrome-less? (Score:4, Informative)
Actually the interface in Mozilla browsers is called the chrome. Mozilla was already using the name for years when Google released their project. You could even say Google. Now that Mozilla allows developers to create their own interface (thus chrome) they called it chromeless, because an interface does not yet exist, the developer can create their own.
As someone who's struggling with the mess of XPCOM (Score:2)
Unique information, (Score:1)
Change... change.. change (Score:1)
That sucks... I used to have a PRISM shortcut to open a Live Excel spreadsheet which I used to annotate daily tasks (pomodoro style) online without having to open the whole browser. Unfortunately it does not work with the minefield builds anymore.
One of the reasons technologies do not "mature" is because developers keep jumping between different alternatives after they get "bored" with the current ones :(.
Where's the link to Mozilla labs blog post? (Score:1)
Chrome (Score:2)
It should be noted that "chrome" is the name of Mozilla's xml-based user interface (not the web rendering engine). It is unrelated to Chromium or Google.
Who you gonna call? (Score:2)
based on XUL (pronounced ZUUL). I ain't afraid of no app.