It's very appropriate you quoted "real" because...
if it's an OEM drive, which is 99% of what you are buying thru pricewatch.com, FORGET IT. You have NO WARRANTY with IBM.
I had the usual 60GXP saga and IBM refused to exchange it although drive was less than 1 year old. Of course the internet shop I bought it from was history by then.
While database API encapsulation is usefull and welcomed, another attempt to integrate GUI and database will surely fail. I love Borland Delphi to death, but data-aware controls suck even there. It looked like a good idea, but I wish it would just die. Problem with them is that they buy you some productivity upfront, but then you just gonna hit the wall of limitations, with no way out. And at this point you are stuck too deep in a project to change every QtDbWhatever to QtWhatever.
My advice to TrollTech: if you are going to do something simular to Delphi, don't even bother!
So we both agree that HTML is bad for RPC, and you arguments for SOAP over CORBA (pls. correct me if I cite them wrong) are:
1) SOAP scales better, because it's stateless.
CORBA object can be made stateless too, you know. It's up to a system designer. Inability to use state actually is a big disadvantage in some systems as performance suffers and implementation gets complicated. CORBA gives you a choice. SOAP doesn't.
2) SOAP is lighter.
Let's see. With SOAP you need at least a full blown web server and XML-DOM parser. ORB-runtime usually is just a shared library. I'm not sure what you definition of lightness is.
3) SOAP is firewall-friendly
IIOP can be tunneled through HTTP as easily as anything else. There are plenty of IIOP/HTTP gateways. Why reinvent the wheel when this is so easy?
Don't get me wrong I'm not against XML in general, it's useful. But XML-RPC is just a hype child that does not offer any substantial advantages over well-designed, open and mature technology, which CORBA is today.
KN
Re:no advantage of .NET over Java
on
Perl and .NET
·
· Score: 1
Exactly! JVM byte code was designed with one language in mind - Java. If those other JVM compilers weren't total crap, wouldn't you think we had some decent legacy software running in JVM by now? If MS really delivers on cross-language and cross-platform aspect, Java has no chance of surviving.
So? It's just an HTTP POST request. The XML document is probably less than 500 bytes long. It's no more expensive than POST-ing a typical HTML form (which is what browsers do for a living).
500 bytes is a huge IIOP packet. The same semantic could probably be expressed using 1/10 of a bandwidth in CORBA.
To handle a SOAP request, the software must not only handle the HTTP protocol, but also build a DOM tree from the request body and act on the nodes of that tree. So? Acting on the request itself (e.g. "buy 10 roses") is likely to be 100x slower than building the DOM tree.
But that's only if you want "to buy roses". What if you want to stream video? Or have real-time quake session? Because if all you want is to buy roses, frankly I don't see what's wrong with the current HTML-Form post.
DOM trees get built all the time for HTML documents. Why is building an XML DOM tree any worse?
Why do you insist on comparing this to HTML? HTML was never designed for RPC. IIOP is.
The point is that while SOAP may not be the most lightning-fast way to accomplish a particular remote method invocation, it is extremely scalable and flexible.
How is it more scalable or flexible then CORBA? Any proof?
SOAP, XML and HTML encoding is just a waste of bandwidth and latency for people who get confused by binary protocols.:)
Exactly! In addition LinkSys/NetGear router functions as a hub/switch for home LAN, which you'll need anyway, at a very reasonable price of ~$150 for 10/100 8-port version.
And where you going to get apps? Porting is very tricky, so having a well-supported API is a huge advantage. That's why we still have Windows, X11, x86 etc. The only solution to this is emulation, which has its share of problems, most notably accuracy and performance.
EROS security and persistence are interesting academically, but in a real world there are technologies (ACL, redundant fault-tolerance, Win2K Hibernate) that can deliver similar capabilities to legacy systems.
So, what you are saying is that Crusoe concept is interesting? So is FX!32, Napster, Iridium...
Being interesting does not make a product successful in a market place.
What I hear about Crusoe is that it gives 10% battery increase for 30% drop in performance in
an average notebook.
I think I'll pass...
BS! Win32 loader maps DLL code segment into a process address space. Load will only happen once. There is nothing not PIC about DLLs in Win32 either - they can and very often are rebased to a different address.
Why some people don't get it - I'll never now! Statically linked VCL creates the bloat, not a compiler. And you do have two other options: 1) don't use it 2) place it into a shared lib(DLL, via packages).
That's why they invented RPMs. End-user don't need to build software, developer do. Kylix is a developer's product and any serious developer should buy it, as it's arguable the best Compiler/Ide/Library created.
"We don't need it we already have gcc". Well, then we don't need a car as bicycle serves our transportation needs just fine. Surprisingly most people, judging by comments in this thread, apparently have no idea what Delphi/C++ Builder is but still feel a need to comment on the subject.
My personal opinion on this(somebody who programs Unix and NT for a living using all kinds of tools like C++, Perl, Smalltalk, Delphi and Java): Delphi port is the most significant Linux port there is. Netscape and Oracle ports are nothing comparing to push this would give to Linux. There is simply nothing out there that gives comparable performance, convenience and productivity. Not even close. I'd give my money to Borland any day for this thing.
Slashdot Mirror
It's very appropriate you quoted "real" because...
if it's an OEM drive, which is 99% of what you are buying thru pricewatch.com, FORGET IT. You have NO WARRANTY with IBM.
I had the usual 60GXP saga and IBM refused to exchange it although drive was less than 1 year old. Of course the internet shop I bought it from was history by then.
So, please do yourself a favor and check
You want a good warranty and a company behind a product - buy Maxtor.
While database API encapsulation is usefull and welcomed, another attempt to integrate GUI and database will surely fail. I love Borland Delphi to death, but data-aware controls suck even there. It looked like a good idea, but I wish it would just die. Problem with them is that they buy you some productivity upfront, but then you just gonna hit the wall of limitations, with no way out. And at this point you are stuck too deep in a project to change every QtDbWhatever to QtWhatever.
My advice to TrollTech: if you are going to do something simular to Delphi, don't even bother!
So we both agree that HTML is bad for RPC, and you arguments for SOAP over CORBA (pls. correct me if I cite them wrong) are:
1) SOAP scales better, because it's stateless.
CORBA object can be made stateless too, you know. It's up to a system designer. Inability to use state actually is a big disadvantage in some systems as performance suffers and implementation gets complicated. CORBA gives you a choice. SOAP doesn't.
2) SOAP is lighter.
Let's see. With SOAP you need at least a full blown web server and XML-DOM parser. ORB-runtime usually is just a shared library. I'm not sure what you definition of lightness is.
3) SOAP is firewall-friendly
IIOP can be tunneled through HTTP as easily as anything else. There are plenty of IIOP/HTTP gateways. Why reinvent the wheel when this is so easy?
Don't get me wrong I'm not against XML in general, it's useful. But XML-RPC is just a hype child that does not offer any substantial advantages over well-designed, open and mature technology, which CORBA is today.
KN
Exactly! JVM byte code was designed with one language in mind - Java. If those other JVM compilers weren't total crap, wouldn't you think we had some decent legacy software running in JVM by now? If MS really delivers on cross-language and cross-platform aspect, Java has no chance of surviving.
So? It's just an HTTP POST request. The XML document is probably less than 500 bytes long. It's no more expensive than POST-ing a typical HTML form (which is what browsers do for a living).
:)
500 bytes is a huge IIOP packet. The same semantic could probably be expressed using 1/10 of a bandwidth in CORBA.
To handle a SOAP request, the software must not only handle the HTTP protocol, but also build a DOM tree from the request body and act on the nodes of that tree. So? Acting on the request itself (e.g. "buy 10 roses") is likely to be 100x slower than building the DOM tree.
But that's only if you want "to buy roses". What if you want to stream video? Or have real-time quake session? Because if all you want is to buy roses, frankly I don't see what's wrong with the current HTML-Form post.
DOM trees get built all the time for HTML documents. Why is building an XML DOM tree any worse?
Why do you insist on comparing this to HTML? HTML was never designed for RPC. IIOP is.
The point is that while SOAP may not be the most lightning-fast way to accomplish a particular remote method invocation, it is extremely scalable and flexible.
How is it more scalable or flexible then CORBA? Any proof?
SOAP, XML and HTML encoding is just a waste of bandwidth and latency for people who get confused by binary protocols.
Exactly! In addition LinkSys/NetGear router functions as a hub/switch for home LAN, which you'll need anyway, at a very reasonable price of ~$150 for 10/100 8-port version.
And where you going to get apps? Porting is very tricky, so having a well-supported API is a huge advantage. That's why we still have Windows, X11, x86 etc. The only solution to this is emulation, which has its share of problems, most notably accuracy and performance.
EROS security and persistence are interesting academically, but in a real world there are technologies (ACL, redundant fault-tolerance, Win2K Hibernate) that can deliver similar capabilities to legacy systems.
In addition PS2 is totally closed platform, so prepare to shell huge $ for SDK (>$10,000).
So, what you are saying is that Crusoe concept is interesting? So is FX!32, Napster, Iridium... Being interesting does not make a product successful in a market place. What I hear about Crusoe is that it gives 10% battery increase for 30% drop in performance in an average notebook. I think I'll pass...
Vaporware!
Sure, I can even translate C into COBOL. But what the hell for? JVM bytecode is too high level to be practical for any pointer manipulating language.
BS! Win32 loader maps DLL code segment into a process address space. Load will only happen once. There is nothing not PIC about DLLs in Win32 either - they can and very often are rebased to a different address.
Exactly! Pricewise and featurewise Raite is the best deal going.
Why some people don't get it - I'll never now! Statically linked VCL creates the bloat, not a compiler. And you do have two other options: 1) don't use it 2) place it into a shared lib(DLL, via packages).
That's why they invented RPMs. End-user don't need to build software, developer do. Kylix is a developer's product and any serious developer should buy it, as it's arguable the best Compiler/Ide/Library created.
"We don't need it we already have gcc". Well, then we don't need a car as bicycle serves our transportation needs just fine. Surprisingly most people, judging by comments in this thread, apparently have no idea what Delphi/C++ Builder is but still feel a need to comment on the subject.
My personal opinion on this(somebody who programs Unix and NT for a living using all kinds of tools like C++, Perl, Smalltalk, Delphi and Java):
Delphi port is the most significant Linux port there is. Netscape and Oracle ports are nothing comparing to push this would give to Linux. There is simply nothing out there that gives comparable performance, convenience and productivity. Not even close. I'd give my money to Borland any day for this thing.