Slashdot Mirror

Do IE and Mozilla actually run standards based JScript well today?

For the most part, yes. Its definitely much better than it was back in the Netscape 3/4 days. Much of Mozilla's UI is done with Javascript so I think that makes the implementation better than before as bugs in JS could cause bugs in the UI.

IE's Jscript still isn't up to that level, but again its better than it used to be. The DOM is almost identical and that helps. IE 5+ also has implemented "getElementById()" and done away with the old "document.all" style of finding page elements.

There are a few differences. This page, is a short informative look at a few of the major differences and some ways to get around them.

That's simply not true. It's currently very easy to write all-modern-browsers compatible javascript. Each release browsers are closer and closer to the W3C standards. JavaScript errors are only caused by developer ignorance. If you are a "IE-only" web developers here are some hints to also code for Mozilla.

Also: Slashdot (the founders/owners/editors) is notorious for saying one thing and doing another. Witness the virulent anti-DMCA stance, yet, notice also how they support the very companies who forced it upon us (aka Sony). Witness their yammering about IE/MS not following standards when in fact their own HTML on thier own site is grossly out of established standards.

Completely true. I've filed a bug to the slashdot bug report page in sourceforge to add some semantic tags to the ones we are allowed to use. I'd like to use , , etc. The bug was deleted as quick as it was posible, with no explanation.

Besides, not only the HTML code doesn't validate. but also Slashdot has blocked the W3C validator!. That's very stupid, as anyone can just download and validate the page uploading it to the validator. Here is the validation result.

After downloading Mozilla you can install Java and Flash automatically.

when you use this one:

Flash and Java installer for Mozilla

Worked absolutely wonderful.

Bye egghat.

http://mazinger.technisys.com.ar/pruebas-nick/mozi lla/

Be my guest. =) You can include a pointer to my page for installing plugins too (check it out).

This is my experience with XML-RPC:

I work for a company (Technisys) which have created several years ago an RPC tool called "tmgen". This tool is built as a layer on top of rpcgen, adding session cookie handling, SSL support, a stateless server, handling of enumerated values with associated long and short descriptions, and many other thing. It's in fact, an application server built on top of RPC.

This baby have been running for many years in the most important banks and credit cards companies here in Argentina (yes, you know the brands, but I'm not sure I can tell you which ones =) ).

The "tmgen" tool reads a ".def" file that defines the datatyes, and ".trn" files which have the code of the different "transactions". Having read those files, it automatically generates the server source (including the rpcgen input source).

I was asked to make it possible for the clients to be programmed in the Java language. I evaluated several possibilities, one of them using a Java client for RPC. This required us to go for a proprietary solution, besides, being in control of both sides it looked silly to be tied to a protocol. Another possibility would have been to modify tmgen to create an RMI server. But the best was to create an XML server (IMO). I then evaluated SOAP and XML-RPC. SOAP seemed very nice, but XML-RPC was *direct* mapping of the semantics and types of our existing solution. The benefits of SOAP were a drawback in this case, we just wanted to have strings, structs, ints and floats.

So, now it's working. It takes a definition of the structs, the method and which parameters they get, and it creates code (using the gnome-xml library (which I recommend). The automatically generated code works as a standalone inetd webserver which reads an XML-RPC query from the net, parses the query, loads it in the generated C structures, run the "transaction", and creates a response from the reply structures. The final result was that all those old C, RPC-only, programs started to have an XML interface.

I added the Helma RPC-XML client and voila, we had a Java client. So I must say that my experience in this legacy system with XML-RPC was great.

Talking about new systems, I think that XML-RPC does the wrong thing, by defining markup for the types instead of marking the semantic of the data.

I hope I haven't bored anyone with my experience.