... RPC-style "web" services such as SOAP and XML-RPC should not be an option. They're contrary to the architecture to the Web. If anything, they should be called RPC over HTTP or something similar, because that is all they have in common with the Web.
Look, I know this -2 (Offtopic, Troll) but why in god's name are you developing applications for Windows phones? You should be building apps for J2ME. *All* of the major phone manufacturers (Nokia, Sony-Ericsson, Motorola, Siemens, etc) are already supporting J2ME - I can't count the number of models of phones that support J2ME on both hands, but I can count the number of Windows phones with no hands.
Switching to J2ME also solves your code-signing issue; you don't have to sign your programs at all.
Now my plans for taking over the world using hordes of CLDC/MIDP MIDlets, all communicating via Bluetooth, can be realised! Soon, your phone will become your worst enemy...
But seriously, I've heard this release includes an implementation of JSR-82, the standard Java API for Bluetooth. This will be very cool, you'll be able to write java apps for the P800 which can do Bluetooth!
Yeah, it really looks fantastic! I've gotten to the tire, boring stage in my life where I'm sick of headling with n number of apps on my desktop with n number of look and feels. I want consistency.
I have Gnome2, I have Moz/GKT2, I'll soon have EMACS/GTK2, and perhaps now OO/GTK2.
This might actually get me using it. If only they can improve the startup time as well..
"Care to explain how you would do it in a more "architecturally sound manner"?"
For a web site? Use REST. For anything else? Use a well designed IPC protocol.
"If there's a programming flaw that allows you access to Amex's customer database it could just as easily occur in the website."
Sigh. If a security hole is found in a webserver, the impact will likely be far, far less than if a hole is found in a SOAP implementation. The difference is what people are going to do with the technology, and how they are going to do it. What SOAP's role in a software architecture is. A web site won't let you *directly* query customer records, or *directly* make purchases. A SOAP API will.
"SOAP definitely has its place".
No it doesn't. It violates the Web and Internet architectures. It makes it easy to get around network security. It piggy-backs on application-level protocols which it shoudn't. It pretends to not be an application-level protocol when it is.
Whilst it looks nice, SOAP is quite fundamentally broken.
No, you are still wrong. SOAP really has nothing to do with web sites.
It *can* be used by web sites to provide an API for programmatic access to that site's data and functionality, but using SOAP in this manner is actually quite redundant: You can do the same thing without SOAP and in a more architecturally sound manner.
This is beside the point, however. SOAP has nothing to do with the web, or web sites, other than the fact it uses HTTP as it's default transport.
SOAP was a spin-off of XML-RPC. Dave Winer developed XML-RPC as a simple RPC mechanism for Userland Frontier, to allow other applications integrate with it. Microsoft picked XML-RPC up (probably becuase it is very buzzword-compilant, and can easily get through those pesky firewalls), turned it into a RPC mechanism for "objects" - which is a lie, they basically just gave it an extensible type system - and let it loose. See XML-RPC for Newbies for a more detailed early history.
"Um. Kind of like how people are using HTTP and the web for mission critical *manual* data input and presentation?"
No, it is being used for RPC (Remote Procedure Call) - a form of IPC (Inter-Process Communications). This is far more dangerous. People are exposing programmatic interfaces to mission-critical systems. These interfaces allow other computers to manipulate data on those remote mission-critical systems. Think of having direct access to Amex's customer database vs. having access to their web site. It is a massively different situation.
Well, SOAP is designed to allow applications to have access to the kind of context-full information humans would have access to through the web anyway.
Err, no.
SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment.
It is a RPC mechanism which is primarilly layered on top of HTTP. Don't make the mistake that just becuase it typically uses HTTP for transport, or is used in "Web Services" that it will only be used in a benign way, or that it is benign by design.
People are alreay starting to use it for mission critical RPC. It is a disaster waiting to happen.
A VPN provides secure access to a remote network via one or more untrusted networks, typically the Internet. Once a VPN is established, the local endpoint has access to the remote networks's resources including, but not limited to, file, mail, directory, print and web servers. Existing protocols such as IMAP, POP, HTTP, LDAP, NFS and SMB can be used over the VPN in a mostly secure and transaprent manner.
WebDAV is an extension to HTTP - The Hypertext Transport Protocol. HTTP is deisgned to transport hypertext (hence it's name) and other media over via TCP. WebDAV provides distributed authoring and publishing extensions to HTTP to allow, amongst other things, remote collaboration. Using WebDAV for a network file system is akin to using FTP for the same. It is a bad idea.
=> WebDAV is nothing like a VPN.
- "using any number of authentication schemes" does not "lock down" anything at all. - It doesn't matter if you are running it over HTTP or HTTPS. Both are the wrong protocol to use for filesharing. Just like using SOAP over HTTP(S).
Doing everything via HTTP, whether running plain text over port 80, encrypted over port 443 or any other combination is bad practice. One of SOAP's (and WebDAV's) "features" is that it allows you to do stuff over HTTP that would usually otherwise be blocked by a firewall. Want to do RPC? Sure! Just tunnel it through port 80! Want to do file sharing? Sure! Just tunnel it through port 80! This is seriously screwed up. It defeats a primary purpose for which firewalls were invented in the first place; to limit access to dangerous services. Not to mention that using HTTP for everything is a serious architectural design flaw as well.
Putting authentication in front of HTTP and/or tunneling it over SSL does not fix these problems. This IIS exploit du-jour is a perfect example of such.
- Web applications are irrevalent to network security.
A web application should be well designed and implemented, with security in mind. It should be deployed on a network which is properly secured. It should be running on systems which are properly securied. Making a web application secure does not make a network secure (and vice versa). "Irrelevant" is probably a too strong a word, but the security of a network should never be dependent on the security of a web application.
Since XHTML 1.x is just a reformulation of HTML4 as XML, all you need to do is find/devise a good HTML course, and add in the XML/XHTML specific bits such has closing empty tags, well-formedness, etc, etc. It shouldn't bee too hard.
Of course, the other comments posted about the importance of using the correct semantics, the separation of style and content, etc, etc must also be taken into account, but that is true for HTML as well. A good HTML course will focus on that anyway.
You shouldn't need radically different HTML4/XHTML1 courses.
It isn't "walla", dammit! It is "voilà". Next time you want to try to sound cool, at least spell the word correctly! Do you even know what it means? Or what language it heralds from??
Slashdot Mirror
So what virus filtering software are you using?
I'm short on time and patience. Quote in context, or not at all.
-mike
This is clearly a cool concept vehicle, who cares if you can go from zero to dead in less than 2ns?!?
I will buy one of these as son as they go GA.
Live a bit for christ's sake!
... RPC-style "web" services such as SOAP and XML-RPC should not be an option. They're contrary to the architecture to the Web. If anything, they should be called RPC over HTTP or something similar, because that is all they have in common with the Web.
If you want to do a real Web service, use REST.
That would have been better as: "In Soviet Russia, Al Gore invents YOU!"
That's what I keep on telling myself.
Do you often talk to yourself? It sounds like you're having a really, really good conversation.
Oh, at least. In fact, I wouldn't be suprised if there were several gazillion.
/mike
Look, I know this -2 (Offtopic, Troll) but why in god's name are you developing applications for Windows phones? You should be building apps for J2ME. *All* of the major phone manufacturers (Nokia, Sony-Ericsson, Motorola, Siemens, etc) are already supporting J2ME - I can't count the number of models of phones that support J2ME on both hands, but I can count the number of Windows phones with no hands.
Switching to J2ME also solves your code-signing issue; you don't have to sign your programs at all.
/mike
Now my plans for taking over the world using hordes of CLDC/MIDP MIDlets, all communicating via Bluetooth, can be realised! Soon, your phone will become your worst enemy...
But seriously, I've heard this release includes an implementation of JSR-82, the standard Java API for Bluetooth. This will be very cool, you'll be able to write java apps for the P800 which can do Bluetooth!
w00t!
/mike
Purely for performance it seems. As always, google has the answers: M1 Abrams tank use a turbine.
The first search result is pretty interesting.
/mike
Yeah, it really looks fantastic! I've gotten to the tire, boring stage in my life where I'm sick of headling with n number of apps on my desktop with n number of look and feels. I want consistency.
I have Gnome2, I have Moz/GKT2, I'll soon have EMACS/GTK2, and perhaps now OO/GTK2.
This might actually get me using it. If only they can improve the startup time as well..
/mike
I assume you were living in a soceity which considered stealing to be wrong, so yes, you were wrong.
"Care to explain how you would do it in a more "architecturally sound manner"?"
For a web site? Use REST. For anything else? Use a well designed IPC protocol.
"If there's a programming flaw that allows you access to Amex's customer database it could just as easily occur in the website."
Sigh. If a security hole is found in a webserver, the impact will likely be far, far less than if a hole is found in a SOAP implementation. The difference is what people are going to do with the technology, and how they are going to do it. What SOAP's role in a software architecture is. A web site won't let you *directly* query customer records, or *directly* make purchases. A SOAP API will.
"SOAP definitely has its place".
No it doesn't. It violates the Web and Internet architectures. It makes it easy to get around network security. It piggy-backs on application-level protocols which it shoudn't. It pretends to not be an application-level protocol when it is.
Whilst it looks nice, SOAP is quite fundamentally broken.
No, you are still wrong. SOAP really has nothing to do with web sites.
It *can* be used by web sites to provide an API for programmatic access to that site's data and functionality, but using SOAP in this manner is actually quite redundant: You can do the same thing without SOAP and in a more architecturally sound manner.
This is beside the point, however. SOAP has nothing to do with the web, or web sites, other than the fact it uses HTTP as it's default transport.
SOAP was a spin-off of XML-RPC. Dave Winer developed XML-RPC as a simple RPC mechanism for Userland Frontier, to allow other applications integrate with it. Microsoft picked XML-RPC up (probably becuase it is very buzzword-compilant, and can easily get through those pesky firewalls), turned it into a RPC mechanism for "objects" - which is a lie, they basically just gave it an extensible type system - and let it loose. See XML-RPC for Newbies for a more detailed early history.
No, it is being used for RPC (Remote Procedure Call) - a form of IPC (Inter-Process Communications). This is far more dangerous. People are exposing programmatic interfaces to mission-critical systems. These interfaces allow other computers to manipulate data on those remote mission-critical systems. Think of having direct access to Amex's customer database vs. having access to their web site. It is a massively different situation.
/mike
Err, no.
It is a RPC mechanism which is primarilly layered on top of HTTP. Don't make the mistake that just becuase it typically uses HTTP for transport, or is used in "Web Services" that it will only be used in a benign way, or that it is benign by design.
People are alreay starting to use it for mission critical RPC. It is a disaster waiting to happen.
/mike
Sure, I can't wait to hear it...
- WebDAV is *nothing* like a VPN.
A VPN provides secure access to a remote network via one or more untrusted networks, typically the Internet. Once a VPN is established, the local endpoint has access to the remote networks's resources including, but not limited to, file, mail, directory, print and web servers. Existing protocols such as IMAP, POP, HTTP, LDAP, NFS and SMB can be used over the VPN in a mostly secure and transaprent manner.
WebDAV is an extension to HTTP - The Hypertext Transport Protocol. HTTP is deisgned to transport hypertext (hence it's name) and other media over via TCP. WebDAV provides distributed authoring and publishing extensions to HTTP to allow, amongst other things, remote collaboration. Using WebDAV for a network file system is akin to using FTP for the same. It is a bad idea.
=> WebDAV is nothing like a VPN.
- "using any number of authentication schemes" does not "lock down" anything at all.
- It doesn't matter if you are running it over HTTP or HTTPS. Both are the wrong protocol to use for filesharing. Just like using SOAP over HTTP(S).
Doing everything via HTTP, whether running plain text over port 80, encrypted over port 443 or any other combination is bad practice. One of SOAP's (and WebDAV's) "features" is that it allows you to do stuff over HTTP that would usually otherwise be blocked by a firewall. Want to do RPC? Sure! Just tunnel it through port 80! Want to do file sharing? Sure! Just tunnel it through port 80! This is seriously screwed up. It defeats a primary purpose for which firewalls were invented in the first place; to limit access to dangerous services. Not to mention that using HTTP for everything is a serious architectural design flaw as well.
Putting authentication in front of HTTP and/or tunneling it over SSL does not fix these problems. This IIS exploit du-jour is a perfect example of such.
- Web applications are irrevalent to network security.
A web application should be well designed and implemented, with security in mind. It should be deployed on a network which is properly secured. It should be running on systems which are properly securied. Making a web application secure does not make a network secure (and vice versa). "Irrelevant" is probably a too strong a word, but the security of a network should never be dependent on the security of a web application.
/mike
No, it is clear that *you* don't understand security. Specifically:
Please, get a clue.
/mike
Wow, "fucking links". That sounds like fun. Is a fucking link the thing that connects people on a sex chart?
Or do you just have a really fucking limited vocabulary?
Or are you just lacking in human interaction skills?
Or are you just a mindless git?
Or what?
[Note to mods: -1 Offtopic, -1 Flamebait, +1 ParentSubmittedByWanker]
Since XHTML 1.x is just a reformulation of HTML4 as XML, all you need to do is find/devise a good HTML course, and add in the XML/XHTML specific bits such has closing empty tags, well-formedness, etc, etc. It shouldn't bee too hard.
Of course, the other comments posted about the importance of using the correct semantics, the separation of style and content, etc, etc must also be taken into account, but that is true for HTML as well. A good HTML course will focus on that anyway.
You shouldn't need radically different HTML4/XHTML1 courses.
/mike
Ah, that would be due to the fact that it has not yet been checked in.
Err, see what?
Heh, okay, I'll give you that but only if Walla Walla is the pr0n capital of the US (much like Canberra is in Australia).
/mike
http://lxr.mozilla.org/seamonkey/source/netwerk/bu ild/nsNetModule.cpp#835
/mike
HTH
It isn't "walla", dammit! It is "voilà". Next time you want to try to sound cool, at least spell the word correctly! Do you even know what it means? Or what language it heralds from??