It's also possible that XPCOM itself is a hindrance to the Mozilla project. Have they realized the assumed benefits of using a component architecture? Not when I can only write for their platform in maybe four languages, if we're being generous.
It wasn't that long ago that CORBA and DCOM were new and exciting, people were running around talking about how you could assemble standard applications like word processors that pulled components from "all over the Internet." It never happened, because quite frankly, it's a stupid idea for desktop apps. Not everything needs to be a distributed application.
XPCOM came along at about this time, and I'm afraid it's still around more because it's a holdover from that era than because it's a good idea. There are benefits to using a component architecture, but the much simpler KParts, QT, or wxWidgets approaches have those same benefits, are much more usable.
XPCOM and XPConnect are what give XUL/JavaScript access to C++ code. I'd like to know how KParts can reflect C++ objects into the JavaScript engine "without any extra effort." If it's a hindrance to Mozilla, I think it serves its purpose well enough that no one has attempted the big task of replacing it.
Netscape realized the need for a component architecture, and one of the main requirements was the ability to utilize components from JavaScript. It was never meant to be an all-singing, all-dancing component architecture a la CORBA and DCOM. There was no existing technology to fill the need, so one was created.
Now, that doesn't mean people didn't go overboard and turn things that didn't need to be XPCOM components into XPCOM components.;-)
Slashdot Mirror
How anyone can argue that it's not superior to the iPod is blasphemy.
One piece of blasphemy coming right up!
I only have OS X machines. How exactly is the Zune going to be superior to an iPod?
It's also possible that XPCOM itself is a hindrance to the Mozilla project. Have they realized the assumed benefits of using a component architecture? Not when I can only write for their platform in maybe four languages, if we're being generous.
It wasn't that long ago that CORBA and DCOM were new and exciting, people were running around talking about how you could assemble standard applications like word processors that pulled components from "all over the Internet." It never happened, because quite frankly, it's a stupid idea for desktop apps. Not everything needs to be a distributed application.
XPCOM came along at about this time, and I'm afraid it's still around more because it's a holdover from that era than because it's a good idea. There are benefits to using a component architecture, but the much simpler KParts, QT, or wxWidgets approaches have those same benefits, are much more usable.
XPCOM and XPConnect are what give XUL/JavaScript access to C++ code. I'd like to know how KParts can reflect C++ objects into the JavaScript engine "without any extra effort." If it's a hindrance to Mozilla, I think it serves its purpose well enough that no one has attempted the big task of replacing it.
Netscape realized the need for a component architecture, and one of the main requirements was the ability to utilize components from JavaScript. It was never meant to be an all-singing, all-dancing component architecture a la CORBA and DCOM. There was no existing technology to fill the need, so one was created.
Now, that doesn't mean people didn't go overboard and turn things that didn't need to be XPCOM components into XPCOM components.
heck even the Mac can't hold its own against Visio (plus OSX requires the much more expensive Illustrator just to match CorelDraw...)
Actually, have you looked at OmniGraffle? Some swear it's better than Visio. (I haven't used enough of either to any comparison.)
Umm, hello? Did you bother to read at all? This thing records HD.
Have you priced an HD DirecTivo or the DishNetwork HD PVR? They're $1000.