ECMA, standard and Microsoft

Posted 30 Jul 2001 at 06:28 UTC by adulau Share This

Ximiam will use the ECMA standard for C# and common language Infrastructure for building the Mono software and architecture. But if you check history, ECMA document is not really well supported by Microsoft...

You can see the official deposed document to ECMA on the microsoft msdn/ecma .

So we can say great, it's a good point for Microsoft. One interresting question is : "Is there any other well-used ECMA standard ? ". The more well-known ECMA standard is Javascript (it's deposed to ECMA).

Is Microsoft support the javascript ECMA standard ? yes and no ....

As you can see, the extension incompatible with the ECMA standard are around VBScript and some other stuff, the part that can cause trouble of using Microsoft products or not in a entreprise for example.

Is the same thing can exist with the C# standard ? Of course. Can we trust Microsoft ? Can we trust standard bodies like ECMA ? What is the best way for creating and protecting standard (IETF, W3C, ISO, ECMA ...) ?

Implementation and testing, posted 30 Jul 2001 at 07:17 UTC by robla » (Master)

I'm going to say some things that generically hold true for any vendor, not just Microsoft:

When the vendor plays by the rules, then engage them. Implement the standard in an interoperable way, ensure there exist test suites. Make standards compliance matter by making interoperability a factor, and by making standards compliance measurable.

What's interesting about C# is that Microsoft bothered to submit it to a standards group. From what I understand, that isn't true of Java, Perl, Python, Ruby, Tcl or very many other languages out there. Perhaps what's needed is for someone to counterpropose one of the other languages; perhaps what the community should do is embrace C#. Regardless, fretting about whether or not Microsoft will dominate the standard while doing nothing will almost certainly lead to that being a self-fulfilling prophesy.

submit to standard group useful ?, posted 30 Jul 2001 at 12:59 UTC by adulau » (Journeyer)

For my personal point of vue, I have seen multiple security protocol submited to multiple standard body (obscure and well-known one).

Everytime, multiples troubles come around :

- Process for doing the official/standard document take times. - Access to published document can be difficult. - Procedure are difficult to follow and sometimes impossible... - The standard organisation is moving slower than the protocol itself

I think, one of the best way, it's to release the source code and the documentation under a license like GPL. (Perl is a good example)

Yes, I know the GPL is not a standard body but some functionnality of the GPL protect the standard itself :

- Force to release the source code for distributed modification. (Java-MS is a good example, SUN should release JAVA under GPL) - Keep consistence around source code.

Maybe an orientation with GPL + a standard org (like IETF) could be the best solution for keeping standard.

Just some idea...


does it matter?, posted 30 Jul 2001 at 16:54 UTC by RyanMuldoon » (Journeyer)

One thing that I keep seeing (and thinking myself) is the question of whether Microsoft will actually stick to their submitted standards. The common assumption is that they will not. This may very well be true. But, people derive from this that Ximian/Mono/Free Software will be ruined as a result. I really can't see how this is true. Let's assume that Mono does end up in some kind of complete state by next summer. And let's assume that .NET is rolled out with great fanfare, and is subtley incompatible to the ECMA standard (and hence, Mono). Do we lose everything? No. We're still left with a pretty cool development environment, another language that we can use if we want, and the ability to let languages use each other's libraries and objects in a nice way. That seems like a pretty big win. And even further, it will be nearly trivial for windows people to start developing free software in linux, as the development environment will be really close, if not identical. That's a huge win. Even if there are small differences, that still makes it pretty easy to port things. And, if the linux market ends up being big enough for companies to care about (as it likely will be), then they will bitch to microsoft for going against their own standard. Much of Mono is being written *with* the Visual Studio .NET development tools, so at least so far, anyway, Mono is compatible with the windows stuff. At this point, if in a year microsoft changes the .NET standard, they will burn themselves just as badly as Ximian. They will have a lot of software and services deployed by then. And that isn't even including 3rd party vendors that are loyal to the Microsoft way. So, in this instance, it seems like it would be really against Microsoft's interests to change the APIs drastically. Mono has a pretty good chance, I'd say.

Why is Mono worthwhile, posted 30 Jul 2001 at 17:03 UTC by rooneg » (Master)

Personally, I'm working on Mono because I think c# and the related class libraries make a pretty good development environment, and I would like to be able to use it on unix. (Specifically on FreeBSD, my OS of choice) If Mono (or a project like it) doesn't provide that environment, I would most likely end up using the FreeBSD tools Microsoft is apparently going to provide. I would prefer to use free tools, so I'll work to make that possible.

Also, working on Mono is giving me a good opportunity to learn c#, which may come in handy in the future.

So just keep in mind, not all of us are in this to counter .NET or bring down Microsoft, some of us just want some neat stuff to play with, and personally, I think that's worthwhile.

existing infrastructure gains weight, posted 1 Aug 2001 at 15:02 UTC by lkcl » (Master)

i'd like to reinforce what RyanMuldoon's saying, here. imagine that you are a large company. large company's have to have support infrastructure. every phone call received, every email received, is a waste of their money. the larger the software-base, the more money wasted.

so what do you do? well, a) you make sure that the 'defaults' are such that the general-idiots can do *anything*. why do you imagine that JavaScript etc is enabled by default on email? the cost of having several stupid phone calls 'my email don't view properly' *far* outweighs the cost - to MrLargeCompany - of a virus hitting the entire world and costing everyone *but* MrLargeCompany billions in currency-of-choice.

[this one's more programming related] b) whenever you write an API, you make damn sure it's 1) negotiable for backwards-compatible support WHEN YOU FIRST DESIGN IT i.e. your first release *has* to have the means to say, in a client-request 'i support these features!' and the server-response to say 'i support only these features!' and both client and server AND these feature-sets together to get the common set that they will use. 2) make sure that there's room to add extra features, and reserve the right to add them! :)

now, i've seen this approach used in several different places, and of course the nastiest one of them all is SMB, which has had layer upon layer of cruft added over the years [it has 7 different dialects, followed by 16 different Capability bits, followed by 8 bits of Flags! and, just recently, the security mechanism for authentication has *also* had the above client/server feature-negotiation added, but that's only available when you negotiate one of the Capability bits - CAP_EXTENDED_SECURITY :) :) :)]

why bother? why do this? why go to all this trouble? well, for the answer to _that_, go back to a) above. off the top of my head, i can think of... 5 separate locations in which microsoft uses negotiation like this. no, six. almost all of them are security-related.

and all to avoid the awkwardness of breaking backwards-compatibility, even at the expense of security, to save on phone calls and support nightmares.

in other words, i think that the probability that microsoft will go off into the blue yonder, as ryan says, is highly unlikely.

what they _are_ likely to do, however, is to move the goalposts by adding extensions that they _don't_ tell you about. and the worst one for that is going to be Authentication / Encryption / Security. for example, an extension to HTTP [yes, that's right: an extension to HTTP] to allow transparent negotiation of security underneath SOAP was proposed over a year ago [new methods M_GET and M_PUT, if i recall correctly. i'm looking for references at mo, and i _think_ what i found then, but can't find now, was SASL].

so, please: watch out. great. encouraging. v. pleased to see that ms is adopting standards. v. pleased to see that other people are implementing them too, esp. open source. watch out for having your feet kicked out from under you, _and_ then their jack-boot on your head in the form of the DMCA.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page