| Weblog: | Web Services, Weblogs and the Future. | |
| Subject: | XML-RPC battles | |
| Date: | 2003-05-26 15:35:34 | |
| From: | anonymous2 | |
|
Response to: XML-RPC battles
|
||
|
Dear Anonymous, go forth and innovate. Just don't call it XML-RPC and everyone should be happy.
|
||
Showing messages 1 through 4 of 4.
-
XML-RPC battles
2003-05-26 16:59:04 Timothy Appnel [Reply | View]
I would begin with the first point in my post -- international character support. How would you provide it in a frozen specification that explicitly states strings to be ASCII? -
XML-RPC battles
2003-05-27 18:48:41 anonymous2 [Reply | View]
Read the archive of the XML-RPC mail list. This issue comes up regularly. I get tired of doing repeat performances. XML-RPC is so deployed it just can't be changed, not by anyone. If you do a little digging you'll see how other smart people have dealt with this issue. I've given my opinion more than once. Dave -
XML-RPC battles
2003-05-28 18:44:30 anonymous2 [Reply | View]
I'll agree there.
I took a good look at it once.
I had to ask myself what XML-RPC really was.
Basically, XML-RPC is a Remote Procedure Call.
You pass variables, you get variables back, or an error. -
Smart implementation of international character support?
2003-05-28 01:23:22 Timothy Appnel [Reply | View]
I'm aware of these workarounds. As I've noted there are a number of different solutions including breaking from the specification to support UTF8. I would be curious to hear what users working with languages that don't fit into ASCII think.
There are different degrees of smart. Smart workarounds. Yes. Smart implementation of international character support. No.
"XML-RPC is so deployed it just can't be changed, not by anyone."
This is at the heart of my point. If XML-RPC cannot be evolved then indeed it is not the right thing for a publishing API to go forward with.
| Showing messages 1 through 4 of 4. |




