Talk:Microsoft Silverlight/archivelist/Archive 2

From Wikipedia, the free encyclopedia

Contents

[edit] About links

I have removed some links in reference because this section turned into a farm link with lot of links added by the trick of a citation that is here just to add the link. The linked sites are not reference actually, there are posts of blogs from anonymous persons. Please do not restore the links. And I have not removed all of them yet. If you are sure the links are useful, please put them below for approval but in my mind, these are external links, not references. Macaldo 18:45, 8 October 2007 (UTC)

All of them are references, not external links (see my response at User talk:Macaldo#Microsoft Silverlight). I am including them here for easier referencing. Almost all of them are from the offlicial team blogs or blogs of developers and program managers who are working (or have worked) on the project. These sources are as canonical as sources can get.
These definitely are references. http://blogs.msdn.com/jasonz/archive/2007/05/11/code-sample-is-your-process-using-the-silverlight-clr.aspx is used to source "Version 1.1 will include a complete version of the .NET Common Language Runtime, named CoreCLR" ("coreclr.dll is the name of the Silverlight CLR engine" from the linked article). "However, in the current release of Silverlight 1.1, cross domain communication is not allowed" is sourced from http://dotnetaddict.dotnetdevelopersjournal.com/silverlight_beta_or_alpha.htm ("Note that the 1.1 alpha version doesn't allow cross-domain access, so you'll still have to drop in server-side service proxies for accessing remote services"). "It is done by creating a XAML Canvas with its width and height set to zero, and using its code-behind code to modify the Document Object Model of the HTML page via the APIs in the System.Browser namespace" is sourced from http://blogs.msdn.com/tims/archive/2007/06/13/programming-html-with-c.aspx ("All the magic necessary to accomplish this is contained in a new .NET namespace introduced with Silverlight 1.1, called System.Windows.Browser"). "Visual Studio's CLR Remote Cross Platform Debugging feature can be used to debug Silverlight applications running on a different platform as well." is sourced from http://blogs.msdn.com/nigel/archive/2007/05/09/mix07-your-product-is-a-feature-of-the-web.aspx ("Now, not only do we support running applications on the Mac, we also support debugging the applications on the Mac. So, for example, we'll go here in Visual Studio now, and one of the things you can see that's kind of cool is we have a feature called Attach to Process. And you'll notice we now have a new option here called CLR Remote Cross Platform Debugging. You can tell that a dev actually named that feature"). "Silverlight can be viewed as a web extension of the Windows Presentation Foundation (WPF), a .NET 3.0 technology and not simply as a new web technology. As such, it makes sense that Silverlight uses XAML, not SVG. If Silverlight were based on SVG, then there would be a chasm between Silverlight and the .NET Framework, but as it stands Silverlight's use of XAML makes it part of the .NET family. In fact, it’s important to note that elements in XAML usually represent objects in the .NET Framework; this would simply not be possible in SVG." is from http://www.netfxharmonics.com/2007/06/Silverlights-Adoption-as-Public-De-Facto-Standard.aspx quoted verbatim. That accounts for all of them. --soum talk 09:34, 10 October 2007 (UTC)
I have removed a link cited twice in reference and that proves this reference section is heavily spammed. But this is not MY problem and I require more advices from other users about that. Macaldo 15:31, 6 November 2007 (UTC)
I gave you a list of what is reffed from where for a substantial number of the links. Isn't that evidence enough to judge their validity. True, most are blog links but they are blogs of the official developers (including Microsoft and Novell) and are thus canonical. Others are of known analysts and .net experts. Those too count as reliable sources. True, there might a link or two that might be invalid, but characterizing everything as spam without giving any reason why (especially when evidence to the contrary has been provided) does not help. What you corrected was not evidence either; it was a mistake. Everyone knows working with the ref tags in anything but a trivial article is a major editing pain. The information was added at different times, and finding references used earlier is nothing short of a nightmare. --soum talk 02:24, 7 November 2007 (UTC)

[edit] Silverlight 2.0

Silverlight 1.1 has been renamed Silverlight 2.0 http://blogs.msdn.com/tims/archive/2007/11/29/silverlight-1-1-is-now-silverlight-2-0.aspx 74.65.42.5 (talk) 20:45, 29 November 2007 (UTC)

[edit] Proprietary?

User harumphy wants it in the first sentence. This was discussed previously, around June 21 2007. AFAICT, He's the only participant who insists on it. I agree with others who say that it's out of place there. It isn't particularly relevant to the average reader, and if it was really important it would appear in the opening of most articles on software products. I'd like to remove it from the opening. Leotohill (talk) 02:39, 11 December 2007 (UTC)

Like I said before, I don't feel strongly either way about this. But here's my two cents. Promoting the licensing model in the operning line only puts undue stress on it, as if it were advertising it either as a good or bad thing. The user does not need us to make their decisions for them. It needs to be mentioned with more subtlety. I feel the infobox is the best place to mention this, as it is not in-your-face, yet is provides more visibility. Almost everyone first looks at the infobox to read the summary of the stuff and will not miss it. But (almost) anyone who knows even a tiny bit abt the subject skips the lead and goes directly to the secn that is likely con contain the info s/he is seeking. So, a mention in the lead is not just thrust forcefully to the readers but is also less effective. Those who are just glancing at the page (and not reading it word by word) will miss it. --soum talk 05:09, 11 December 2007 (UTC)
As I've argued before, I think it's crucial. Why? Because the web is built on open, patent-unemcumbered standards, and Silverlight isn't. Thus users can only view Silverlight content using a proprietary plugin. (Other stuff does that too - e.g. Flash and Real, but two 'wrongs' don't make a right.) It's also more serious in this case because the promoter of the plugin has an OS monopoly to defend, and MS has a long and miserable track record of using proprietary standards for anti-competitive purposes. It's not in the public interest for any vendor to achieve lock-in, or even in the interest of unreconstructed MS fanboys. Silverlight's proprietariness is a threat to the openness of the web. That's why it's important. If you don't accept my argument, and feel that its proprietariness is harmless, then why are the MS fanboys who dominate this article so desperate to remove this single word from the one place it might get noticed? Also, the paragraph is too fluffy about the Moonlight vaporware, which might never get finished. --Harumphy (talk) 13:53, 11 December 2007 (UTC)
Harumphy, why is it always you resort to name calling other editors? What is your problem that you cannot act and converse rationally and politely without resorting to calling other editors fanboys and paid executives and what not? It is this attitude that enrages other editors and initiates edit wars. Last time it happened this way, and I can see you dragging it down the same way this time again.
I would again request you to put your MS-bias out of the way in any argument, and argue on the merit of the product, not the company that produces it. That said, "Thus users can only view Silverlight content using a proprietary plugin" and "about the Moonlight vaporware, which might never get finished", is not totally correct. If you follow the Moonlight development, you will see it is totally on track to complete its goal in the target timeframe. So, you have a FOSS alternative too to view Silverlight content (a significant amount already works). As for viability of Moonlight, MS has shared a lot of design specs and conformance tests with Novell. True, MS hasn't made them public, but via Moonlight all but the fluff are as good as available (though it might need some extra work, but they can be created). As for its (moonlight) viability (patent encumberedness), it is going on with MS' support and a public covenant not to sue ([1]), so there is no fear of lawsuits. The only grey area is codecs, but Miguel is lobbying hard to get Ogg certified as a mandatory codec (though it might not be in SL2 timeframe). So, the picture is not as gloomy as you are painting it to be. Btw, the core runtime of SL is already an open spec.
Disclaimer: This is not to be counted as my vote for removal of the word. As I have already stated, I am sold neither way on this topic. --soum talk 14:22, 11 December 2007 (UTC)
My apologies if the term 'fanboy' enraged anyone. That wasn't my intention. Sometimes I write tongue-in-cheek but forget to put the smileys in. :-) :-) :-) Last time I looked at Moonlight's home page, there was no timescale for completion. The codec thing is a *huge* and show-stopping grey area - surely using a patent-free codec like Ogg will only solve the problem if it completely replaces VC-1? Which it presumably won't and can't. And the covenant not to sue applies only to Novell and its customers - that's a small subset. It doesn't solve the substantive patent liability problem at all.--Harumphy (talk) 18:26, 11 December 2007 (UTC)
The covenant not to sue isn't just for Novell, it protects "all downstream recipients of Moonlight" [2]. As for Ogg, its just like having a standard HTML and proprietary extensions. One need not be introduced at the expense of the other. Market forces will choose what prevails. Its tough to make prediction about the time when such a solution does not even exist. Btw, when using Moonlight with ffmpeg as the media stack, it already supports Ogg. As for Moonlight release, it will release with Mono 1.2.6 [3] (see mono roadmap for release timeframe) --soum talk 04:51, 12 December 2007 (UTC)
From the source you cited: An entity or individual is not a Downstream Recipient when such entity or individual resells, licenses, supplies, distributes or otherwise makes available to third parties the Moonlight Implementation. This so-called covenant is hedged with Alice-in-Wonderland definitions that render it worthless. --Harumphy (talk) 12:50, 12 December 2007 (UTC)
The same article says, “Downstream Recipient” means an entity or individual that uses for its intended purpose a Moonlight Implementation obtained directly from Novell or through an Intermediate Recipient and “Intermediate Recipients” means resellers, recipients, and distributors to the extent they are authorized (directly or indirectly) by Novell or its Subsidiaries to resell, license, supply, distribute or otherwise make available Moonlight Implementations. So, IMO, anyone who agrees to the Moonlight license (either obtained directly from Novell or via someone else) is protected as long as they only resell, license, supply, distribute or otherwise make available Moonlight Implementations (which is pretty much everything that can be done). The only exception is bundling with (not distributing for) non-Novell branded Linux (except for resellers, recipients, or distributors who are in the business of offering their own branded operating system software). So, IMO, its pretty much in the safe zone. (Gawd, I am sick of this legal speak. Every line seems to contradict the previous line!!!) --soum talk 16:10, 12 December 2007 (UTC)
I rest my case. --Harumphy (talk) 21:19, 12 December 2007 (UTC)
Me too. --soum talk 05:31, 13 December 2007 (UTC)
Harumphy, I think that it's ok to make that argument about proprietary plugins, but it does require explanation, as you have done here. Simply plopping the word "proprietary" into the first sentence is, as soumyasch said, out of place. The article opening should define what the thing is or does. Considerations regarding its license model should come later. Leotohill (talk) 14:41, 11 December 2007 (UTC)
OK, how about putting the p-word and some explanation into a second paragraph. I think that would be prominent enough. I don't think it should be shunted into the infobox because that is three-quarters of the way to burying it. --Harumphy (talk) 18:26, 11 December 2007 (UTC)
It's not that important. We don't need to explain proprietary software as a cornerstone of explaining what Silverlight is, in the lead section of the article. Distribution models, source code availability, cost, licensing, deprecation/support status, ownership, and any other attribute that apply to any piece of software should go in the Infobox, if only because we want these details to be in a consistent location across our software articles. -/- Warren 21:40, 12 December 2007 (UTC)
That is neither good enough nor a rational approach, because the importance of the licensing model (etc.) isn't always the same. It's much more important where 'network effects' come into play (e.g. web client-server interface) than something completely self-contained (e.g. pocket calculator). Silverlight isn't just a piece of software - it's also in effect a client-server protocol. --Harumphy (talk) 08:23, 13 December 2007 (UTC)
Silverlight - a client server protocol? AFAIK, it is just a content format that you can stream, download, or execute locally over any damn transport protocol. When hosted in browser, it uses the browser's native HTTP(S) transport. It does not plug in its own transport mechanism. In fact, there need not even be a server to run SL apps. Btw, please detail "It's much more important where 'network effects' come into play". As long as the exteral interface is published openly (SL is an implementation of Common Language Infrastructure at its core + a composited rendering engine + some caveats), isn't that enough to let others join the party? (okay, thats an over-simplification, but implementing CLI inside the browser sandbox is a start).--soum talk 12:36, 13 December 2007 (UTC)
No, it probably isn't enough, because AIUI it's patent-encumbered and thus doesn't meet IETF/W3C requirements. (So-called "RAND" isn't enough.) BTW "protocols" needs to be considered across the whole stack, not just the transport layer. --Harumphy (talk) 18:30, 13 December 2007 (UTC)
soum, "content format" would just be a specification for, eh, the format of some content. I know that's not what you meant. SL is, at least,: 1) a graphics renderer and 2) a host for executing code written by application developers. Among other things, SL provides HTTP communication channels to a host server . Given what SL enables, I understand harumphy's point about client-server. Certainly, as more processing and logic is pushed out to the client (the browser), it more resembles my understanding of a client-server model. (which differs significantly from the WP article on it, but that's a different story.) Of course, some web apps today have so much Javascript and Ajax running in the browser, not to mention Flash, that you could argue that they already resemble client-server. Still SL clearly enables a giant step leap further in that direction. It's an interesting point that might be worthy of elaboration here, or in the client-server article.
Regarding the P-word, I totally agree with you, identification of the licensing model does not belong in the opening. Harumphy already agreed that it would be ok to move it out of the first sentence. I'm ok with it just being in infobox - I appreciated Warren's argument for consistency across articles. I'd also be ok with a brief mention of it in the text. Leotohill (talk) 17:50, 13 December 2007 (UTC)

[edit] P-word secn break

Okay, that "content format" probably isnt the most suitable word. But it still defines (albeit very loosely) what SL is - just another way to run RIA "content" in browser. What I don't understand is how it is equated with a "protocol"? You never call HTML a "protocol". Neither Java qualifies as one. A much better term would be an "execution platform" that lies atop the HTTP(S) protocol. It does not need a separate server component, aside from a regular HTTP 1.0/1.1 server. Neither does it provide HTTP communication channels of its own, it uses the browser's capabilities. Neither do I understand how is it more a client-server than, vanilla, HTML. Requesting clarification. As for the p-word, I already said I prefer it in the infobox, but my preference isn't strong enough to push it either way. --soum talk 04:32, 14 December 2007 (UTC)
Protocol probably isn't the best word either. But there is nevertheless something going on in with SL between the server and the client, and it's proprietary. The technical details are largely moot. If web sites publish stuff with it, that puts pressure on users at the client end to use MS technology when they could otherwise do very happily without it. This gives MS leverage against fledgling OSes and/or browsers, thus helping to entrench MS's dominance of both. Opera is now complaining to the EU competition authorities. Moonlight is vaporware and as you (soum) have discovered, when you try to decipher MS's covenant-not-to-sue you will lose the will to live. SL proprietariness is thus a very anti-competitive ploy. We would be doing a disservice to readers of this article if we gloss over this major problem or obfuscate it away into the infobox. It needs spelling out unambiguously and prominently that it's proprietary. I have an open mind about how it's done - all I ask is that it is prominent. --Harumphy (talk) 16:07, 14 December 2007 (UTC)
This is not about the p-word dispute. I am okay with the proposed resolution. I am not going into the debate of what is good for users and whats not. I will leave that decision to users themselves. I am still following this up because I want to know your viewpoints about the techncalities.
Whatever goes on between the client and the server is pure HTTP. You can attach a packet sniffer and verify (I have done it). The proprietary stuff starts after the web server responds with the Silverlight assemblies. The server has no more say. If more communique is required thats just another HTTP GET or POST. Any damn web server that can speak HTTP (Apache, IIS and what not) can be the back end for Silverlight. Btw, Mono 1.2.6 has released and it does contain the Moonlight bits. --soum talk 17:06, 14 December 2007 (UTC)
Can we please stick to the subject instead of going off at tangents? The OP was complaining about the p-word at the beginning of the article. What is this proposed resolution you speak of? Sorry if I'm being thick but I can't see one. --Harumphy (talk) 19:34, 14 December 2007 (UTC)
The one you proposed. Moving the word out of lead sentence to a later position and introducing it in infobox for consistency. I thought that was decided. Anyways, I am not taking sides in this debate. I am only discussing to point out flawed arguments. All my comments were with that intention. --soum talk 03:45, 15 December 2007 (UTC)

[edit] Criticism section

I'm a little worried about this article having a Criticism section where until recently only a small fraction of the text was actually criticism - the rest was further praise for the product as the critical pint was rebuffed in detail. I recently moved that rebuttal out of the section into the main article and changed its wording slightly, to make more sense in the new context. I see that it has been moved back and enhanced so that, even with the extra two critical points I added, about half of the criticism section is now praise or technical explanation.

What is the point of a criticism section if the criticisms are just used as sub-headings leading to ever more detailed praise? How are we going to claim that the article represents a neutral point of view if the Criticism section contains little but further praise? What do other WP articles have in their 'criticism' sections? Should the criticisms be distributed more evenly throughout the article? --Nigelj (talk) 13:38, 12 December 2007 (UTC)

Tell me one thing then: How is promoting a baseless, ill-informed, and practically incorrect comment (that SVG should have been used instead of XAML for the sake of fixing standard incompliance in IE) as a criticism justified on the grounds of WP:NPOV? Remove that point of contention, and there would be no need for rebuttal - neither the explanation, nor any quotations (which, incidentally, was the agreed-upon solution the last time this issue arised). I suggest again restoring the agreed-upon-last-time solution: "Silverlight has been criticized for lack of standards compliance, which according to Ryan Paul of Ars Technica, is in line with MS's ignoring of standards elsewhere as well." (or whatever, it can be retrieved from archives). If needed to back up, some other example except the XAML vs SVG issue can be shown. Only that I would propose a change this time. Lack of standards compliance isn't the most visible criticism, rather narrow platform support is. So, the criticism secn should start with that followed by the Ryan Paul comment.
The other criticism (narrow platform support) is a valid criticism. That does not have (nor can it have) any rebuttal. Criticism should be like that - which cannot have rebuttal. Not like the former one which anyone with a little knowledge can invalidate. --soum talk 15:50, 12 December 2007 (UTC)
And how is saying "this thing has does and does this" constitute as "praise". AFAIK, praising something would be like "zomg...this thing does this!!!...thats so awesome". Where in the article is such thing? --soum talk 15:57, 12 December 2007 (UTC)
I think the whole section is poorly done. First, I suggest renaming it to "Disadvantages" . That would be a good move toward NPOV. It suggests that using the product involves tradeoffs or choices. I think the SVG vs. XAML issue should be reduced to a single sentence, or maybe two. It should say something like "SL does not use the SVG standard for vector graphics, instead using its own XAML-based design. " The concern about cross-platform support should be reduced to "Some are concerned that MS's support for non-Windows implementations of SL may be reduced or withdrawn in the future. " Footnote these as needed. The "Legal Representations" concern doesn't belong there at all. It's not specific to Silverlight. To be consistent, you'd have to put that criticism into every article about a MS product, and that would be silly. Leotohill (talk) 17:43, 12 December 2007 (UTC)
Disadvantage? Compared to what? And if you are doing a comparison (nothing can be disadvantageous without a point of reference), a "Comparison of ..." article is better suited. I wouldn't support converting this to a comparison secn. As for "SL does not use the SVG standard for vector graphics, instead using its own XAML-based design", it does not end the story. SL is basically a .NET Framework-equivalent (almost) execution environment. It supports neither XAML, nor any other language like C# or VB.NET. It only supports CIL and absolutely nothing else. Any other language, including C#, VB.NET, F# as well as markup languages like XAML, must be translated to CIL before use. These translation (compilation) is done using external compilers, which are absolutely independent from SL. Anything that is compiled to CIL works with SL, including SVG if a SVG to CIL compiler is used.
The XAML parser is implemented as a separate library on top of the Silverlight stack. You can very well use SVG if the proper SVG parser (either native or XSLT transformer) is present on the development system (not even required on client system). That way, using SVG isn't at all different from using XAML from the end user perspective. From the development perspective, saying not having a SVG support out-of-the-box is a criticism (or disadvantage) is as good as criticising the C++ standard library for lack of SVG support. If it is not a criticism there, why is it here? --soum talk 18:46, 12 December 2007 (UTC)
Because this point will always be a point of contention, its best to avoid this altogether.--soum talk 18:46, 12 December 2007 (UTC)
I thought the "compared to what" was obvious, but I guess not. Still, I think "Criticism" has become a code word for POV, but so be it. The section name notwithstanding, I think the content should be trimmed way down. Your statements above, about the architecture (or substance) of SL don't really belong in a criticism section - they belong in other sections that describe the product.
I'm trying to help us find a middle ground that we can live with and that promotes the integrity and quality of the article. I think one guideline should be that we avoid hashing out all the pro and con arguments in the article. It makes the article unwieldy, especially on highly technical issues like SVG and XAML. If someone has a criticism that is germane and has some support at large, then it should probably be briefly mentioned, with footnote references to pro and con discussion.
By the way, I'm not sure are you correct that everything must be externally translated to CIL before SL use. I can't reconcile that with what I'm reading at http://msdn2.microsoft.com/en-us/library/bb428859.aspx , especially the "deployment and packaging" part which seems to clearly indicate that the web page package includes XAML. It also can include Javascript, and by implication the other dynamic languages supported in SL 2.0. If I'm not reading this correctly , let me know.
Leotohill (talk) 21:19, 12 December 2007 (UTC)
Thats what I have been saying all along. The comments don't belong in criticism. That should be removed, as was done as part of the resolution last time. Technical issues, like SVG vs XAML, can be tackled in their own comparison table somewhere else. Their comparison does not add to SL's criticism. As is using an inappropritate misinformed SVG vs XAML opinion used to justify a valid criticism. I am removing the example, like last time.
As for your other question, the compilation must happen prior to execution, not necessarily prior to deployment. If the parser/compiler/interpreter is implemented in managed code, SL can load the libraries and compile the code at runtime, on the fly (as with IronPython, IronRuby or markup languages like XAML or other XML based domain specific languages). Precompilation is needed only if the compiler cannot be hosted by SL (C#/VB.NET). As for the JS API, like .NET Fx, SL needs to be hosted in a running process. The host is a browser and os-specific impl. The JS API is exposed by this host (the browser plug in), not SL. It internally marshalls the JS stuff into managed domain functionality (or at least stuff that affects the managed world). --soum talk 05:40, 13 December 2007 (UTC)
Now you are confusing me. Above, you seemed to object both on technical and informational basis to my suggestion that the SVG vs XAML "criticism" be a one-liner, I thought you wanted to add all that stuff you wrote following "...does not end the story." But now you are saying that you DO want to keep it short, without explanation. Or maybe you are saying you don't want any mention of the issue at all. Please clarify for this muddled mind. Leotohill (talk) 06:57, 13 December 2007 (UTC)

[edit] Secn break

My objection is to the "SVG vs XAML criticism" because it is invalid. SVG cannot be used in place of XAML. So, criticizing SL on basis of that does not hold. Now, despite that if the issue is added to the article as an example of the "lack of standards compliance criticism", there has to be a technical refute to it (which cannot be a one liner).
The other solution is to keep out the SVG vs XAML issues altogether. If needed, some other thing can be used for justifying the "lack of standards compliance criticism" but not repat the comment that SVG should have been used in place of XAML just for the sake of making IE standards compliant in a product that is spelled S-I-L-V-E-R-L-G-H-T and aid in promoting the wrong point of view.
I will always champion the latter solution but if other editors insist on adding the wrong and baseless issue to the article, I will be adamant about the refute. --soum talk 11:10, 13 December 2007 (UTC)
We see this now again in Wikipedia - one editor standing up singlehandedly against all other reasonable and considered opinion, citations, references and other input. In this case mudddying the waters with unnecessary technical details and ripping out everything s/he doesn't agree with from the article. It is clear - we have a valid, referenced and cited criticism of an aspect of the topic and so it is reported in the WP article - but not for long ;-)
It's a shame, but it's the way WP works - if some unemployed person, or someone employed to perform the role, has all day every day with little else to to do but to keep an article how they like it, there's not much the rest of us can do. Still, there are plenty of other articles to go and help out on. (Note: I'm not saying that either case applies here, just making a general point before I go) See you guys. --Nigelj (talk) 19:25, 14 December 2007 (UTC)

[edit] Lead

I had to revert the lead, it was not only awfully dumbed down to the extent that it was nowehere near a summary as required by WP:LEAD but incorrect as well. "...software product that allows applications that are accessed with web browsers to provide user-interface features that browsers alone do not typically offer"... - um, no. SL apps can very well use HTML/CSS for the presentation layer with SL being used for code-behind in .NET languages. It might have ABSOLUTELY nothing to do with user interface. RIA is the best term to describe what SL is. "Silverlight version 1.0 includes features that are also present in competing products" ... since when do we do feature-wise comparison of products in the lead section itself. You want comparison, go ahead and create a comparison article. "Future versions of Silverlight are meant to extend the feature set considerably" ... most people are actually intereseted in the extended feature set, namely the CLR integration. "...a subset of the animation, vector graphics, and video playback capabilities of Windows Presentation Foundation" ... is absolutely vital, because SL is not a brand new retained mode graphics runtime but just a web-facing port of WPF using the same architectural underpinnings. If you can specify where its too tough to non-techies we can work out a suitable jargon-busted wording. --soum talk 09:38, 4 January 2008 (UTC)

I hope we can work out something that is closer to my edit than the (reverted) current. Regarding your points: "SL apps can very well use HTML/CSS for the presentation layer with SL being used for code-behind in .NET languages." That's not true in SL 1.0 - there is little if anything it can do except presentation. 2.0 will indeed extend that to allow use of additional languages and programming techniques on the front end. We could try to work that in, but again, it's a future capability so has to be phrased that way.
I really want to avoid requiring the reader to understand RIA before they can have any idea of what SL is/does.
I put in the reference to other products only because many readers will already know what those products are and do, and so allows an immediate understanding of what SL 1.0 does. Perhaps it can be phrased in some way that sounds less like a feature comparison.
You say "most people are actually intereseted in the extended feature set, namely the CLR integration." You are assuming, apparently, that most readers are developers. I don't agree - our perspectives are very different on this point. Many readers will come here because they were prompted for a SL download, or read something in the press.
ditto for the "subset of ... wpf". I strongly believe that this should NOT be in the intro.
I reviewed wp:lead, I think that what I wrote was ok except that it lacked a "why is this important" statement. That should be added. —Preceding unsigned comment added by Leotohill (talk • contribs) 14:24, 4 January 2008 (UTC)
"I hope we can work out something that is closer to my edit" - I am sorry but if you are already so biased in favor of what you wrote instead of what is good for the article will hamper the chances of an amicable resolution. I will still try but be warned that it has already biased me against you and I might not be as reasonable as I would have otherwise been. I apologize in advance.
So you are choosing users over developers? How is that better than the current version which chooses the other way. The lead should present a concise and easily accessible summary, for all, without choosing any way. And what do you gain by sugar coating the lead without saying RIA? For all other softwares, we use the technical name, why this should be different? There are many people who don't know a thing about programming, do we start programming language articles without saying "programming language" for their sake? Anyways, how about, "Microsoft Silverlight is a Rich Internet Application plug-in for web browsers that can be used to provide user interface features, like animation, vector graphics, and video playback capabilities, that browsers alone do not typically offer."
As for being a subset of WPF, it may not be important enough to be in lead. But the issue of codenames, I think, should be there in braces for consistency. And one-liner paragraphs are especially frowned upon in quality reviews.
As for feature set comparison, naming the competitors should be enough for people to realize what is done. We do not need to spell the comparison out.
As for SL 2.0 (which btw, is publicly available already though in an dev version), it takes up a huge chunk of the article. And since the lead summarizes all the aspects of an article, it is too important to be reduced to "Future versions are slated to expand the feature set considerably" (which incidentally is true for all softwares - announced and unannounced, not just SL). As such the most important aspect ofSL 2.0 - CLR integration - should make it to the lead, as it currently is. What part do you think is too techie to turn regular users away? Considering that SL 2.0 mainly contains developer technologies, how to you expect to make it anymore accessible than it already is without dumbing it down to be ineffective? --soum talk 13:35, 5 January 2008 (UTC)
\\
"...if you are already so biased in favor of what you wrote instead of what is good for the article will hamper the chances of an amicable resolution. "
Wow, that's kind of harsh isn't it? I wrote a new intro, you reverted it, we began a discussion here. Have I been too forceful? Has my language been arrogant, antagonistic, or just plain mean? Have I done too many reverts? I'm trying hard to be a good wp citizen. Please assume my WP:Good Faith.
"So you are choosing users over developers? How is that better than the current version which chooses the other way."
This is our biggest difference. For the intro (only) I'm choosing a broader reader population over a narrower one. Won't there be more non-developer readers than developers? And there is ultimately no loss of information - The information of interest to developers will still be in the article.
"And what do you gain by sugar coating the lead without saying RIA? "
Reducing jargon. Following the principle that, as much as possible, it should not be necessary to read other articles in order to understand the intro of one. Sometimes it is necessary, but this time I think not. Also,...
"There are many people who don't know a thing about programming, do we start programming language articles without saying "programming language" for their

sake?"

No, because many, probably most readers will have heard the term "programming language" and will have some notion of what it means. Not so with RIA. That term is relatively

new (a few years at most).

How about a first paragraph that minimizes the developer-centric references, and a second paragraph that introduces those? Here's a new draft:
Silverlight is a software product that allows applications that are accessed with web browsers to provide features that browsers alone do not typically offer. These features include animation, vector graphics, and video playback. While these features are also provided by products such as as Adobe Flash, Apple QuickTime, and Windows Media Player, v2.0 of Silverlight (not yet released) will extend the feature set considerably, allowing developers to use .NET programming languages and capabilities of the .NET Framework to implement Rich Internet applications (browser-based applications with features of non-browser applications).
2nd paragaph: Supported browsers and OS's, and some mention of the overall significance of Silverlight. (if possible - I don't have any words at hand for that, right now.)
The codename reference needs to go somewhere. If there was a History section, I think there. Lacking that, I recommend either as a one-sentence paragraph in the intro, or fit into the Overview section.
Leotohill (talk) 15:54, 5 January 2008 (UTC)


True, you haven't been arrogant with your words or actions but the way I read it made your intentions pretty clear ("I hope we can work out something that is closer to my edit") - that you will get the article the way you want, not what the article needs. Anyways, I am willing to overlook it as a lack of diplomacy on your part :).
As for RIA, the term might have been relatively new (so is Web 2.0 but do we sugarcoat it?) but it is not relatively uncommon. It has been and is being used by the mainstream press in liberal doses. I think we have reached a point where the term isn't just a technical jargon. An embedded defn of the word is enough for the reader to continue reading.
That apart, the article is about SL in general, not SL 1.0 or SL 2.0. As such, we need to make the lead target both versions, not single one out.
I am okay with the structure you proposed for the lead. Except for a few changes. "Silverlight is a software product..." be changed to "Silverlight is a browser plug-in that allows web applications to provide features that browsers alone do not typically offer." But I would still prefer using RIA: "Silverlight is a browser plug-in that allows browsers to access Rich Internet Applications (RIA), which are specialized web applications which are closer in interface and functionality to desktop applications than to web pages, comprising of features like vector graphics, animations and multimedia playback capabilities that browsers alone do not typically offer. Version 2.0 of Silverlight (not yet released) will extend the feature set considerably, allowing developers to author the RIAs using .NET languages." (Too long a sentence? Break it up).
2nd para: SL, which was developed under the codename of WPF/E, is avaiable for <insert platform support here>. Importance has already been established - author platform-independent, language-independent RIAs.
I am still not sold on the comparison part: Why is it needed? I agree with your comment that giving users a reference point will help them understand better. But why do we need to spell it out? Why is saying SL competes with ... and ... isn't enough? --soum talk 10:04, 7 January 2008 (UTC)
\\
I apologize for the unintentional non-diplomatic language.
when you say that ria is being used in the mainstream press, can you back that up? I searched www.nytimes.com for "rich internet" and got only 4 hits over 5 years - none in 2007. Or maybe you mean "mainstream technology press"?
Leotohill (talk) 16:24, 7 January 2008 (UTC)
I am sorry, I meant tech and business press but if you search in any search engine or news aggregators, there is a very widespread usage of the word. And its usage isnt totally limited. Still, I guess I should open an RfC to get a fresh opinion. --soum talk 04:02, 8 January 2008 (UTC)

Ok, I've put a new intro in place. It has some significant changes from the draft I proposed above, which I think help emphasize some of the aspects you wanted in it. Have at it. Leotohill (talk) 06:38, 9 January 2008 (UTC)

I like it. I saw only a few minor copyediting issues and one major isuue: SL 2.0 was characterized wrongly as being not available. It is available, but only in an development version. I updated the article reflecting that. --soum talk 07:04, 9 January 2008 (UTC)

[edit] Hmmm

The current lead, in the second sentence lists vector graphics as the second most important feature that SL adds to browsers, which they "alone do not typically offer". I have two major problems with this and so intend to make some changes very soon.

  1. Opera, Firefox, Netscape, Camino, SeaMonkey and Epiphany all have native support for SVG (see Scalable Vector Graphics#Native support). SVG is an internationally standardised vector graphics spec that supports two-dimensional vector graphics, both static and animated, declarative and scripted. Maybe the author meant, "to provide features that MSIE alone does not typically offer".
  2. I notice that all mention of SVG has been expunged from this article since I recently tidied up its mentions, and tried to give it its correct context here. It should be discussed both as a criticism (that MS have chosen to continue to ignore a well-established international standard) and therefore as a competitor (it is already in wide use on the Web - e.g. in Wikipedia for just one mainstream example)

--Nigelj (talk) 22:59, 9 January 2008 (UTC)

How about changing "that browsers alone do not typically offer" to "that some browsers do not offer"  ? Leotohill (talk) 00:30, 10 January 2008 (UTC)
Why do you keep harping the same tune; as if not repeating a misguided criticism will make SL the perfect software ever written and it seems like you have made it a personal vendetta of yours to prevent that from happening. I say that again, the SVG versus XAML criticism doesn't hold. Let's take a look at the Ryan Paul criticism (SL does not support many open standards and uses proprietary things to the same effect. It should have used existing standards like SVG, that would have been a balm to the wound made by IE's incompetenece). It has three separate parts: 1. SL does not support many open standards, 2. SL should have used SVG instead of XAML, 3. SL should have fixed IE's flaws. Lets see why suggesting SVG be used instead of XAML is wrong:
  • XAML isn't only being used for vector graphics. It is used for vector markup, UI markup and databinding (initially). Even if SVG were used, the other uses would require something else.
  • XAML actually is a generic XML dialect without any specific application. It is only used to instantiate .NET classes and set properties. The keywords are not a part of XAML but are mapped from the underlying classes. As such, if SVG were to be used, either the back-end classes were to be modified or a mapping layer introduced, or the front-end (the SVG language itself) be modified. Conversely, if a .NET class library is used with the same class names as SVG keywords and property names, the XAML markup will be 100% compatible with the SVG markup and can be consumed either by SL or SVG renderer.
  • SL does not technically support XAML. It is implemented as a separate compiler (which can be hosted by SL) that compiles it to CIL.
  • SL is nothing but a web facing port of WPF. When you are porting something, how can you change the spec? Its like suggesting that people use a C++ parser when porting a C# compiler!!!
The other suggestion made was that MS could have used SL as a ship vehicle for fixes made by IE problems? Why should it be so? SL is not an IE-extension but rather a cross-browser thing. Why should it fix IE's flaws then? IE made the mess, IE should clean it up.
The only valid criticism is that SL does not follow many open standards. As far as I can tell, that is prominently mentioned in the article. Feel free to expand on it but don't bring in the SVG vs XAML issue as it lacks any technical base.
But no, thats not enough for the editors. A comment has been made by someone. We must be parrotting it. Any analysis of whether it stands on any firm ground is unnecessary and muddies the water. Self refute is not an option, using someone else's claim is too technical and without context, so it must be moved somewhere else so that the pointless and wrong criticism can go unrefuted. Using commonsense is probably the world's greatest sin! Fuck wikipedia! This is zealotry at best. And standing up against this is "singlehandedly against all other reasonable and considered opinion" (care to explain where the reasoning I have given is wrong and where is your reasoning except that Ryan Paul has spoken just because he has a mouth?)
Sorry if I was a bit rude in the preceding paragraphs. I am sick of dealing with this thing in almost every article. Not in sync with some philosophy? Lets go and game it to make it presented as negatively as possible. I am really sick of this!!! Anyways, the other point you mention has very valid ground. "Browsers alone do not typically offer" is probably a very strong claim to go without a cite (and even inspite of a cite, it will be baseless because it can be easily refuted). Lets see what does SL add:
  • Animation: Was already possible using DHTML/JavaScript and HTML/Time. Supported in probably all browsers in current usage.
  • Vector graphics: IE5+ (using VML: might not be the language people want but it still is vector graphics), FF/Safari/Opera: SVG
  • Interactivity: HTML Forms anyone?
  • Client side persistent offline storage: IE5+ (userData), FF/Safari: DOM Storage, no idea about Opera.
  • Advanced graphics subsystem: FF/Safari/Opera (Canvas), IE (using the DirectX ActiveX controls)
  • REST Web Services: Support HTTP and XML? You already support these then.
  • XML Data Binding: IE5+ (XML Data Islands), no idea about others
So, SL 1.0 provides nothing that isn't typically possible in browsers alone (by that I mean the native browser + extensions that ship with it and are available on a fresh uncustomized install). SL 2.0 allows code behind in languages other than JavaScript, but that was also possible with cross-compilation (SL uses CIL as the intermediate language, JS could very well have been used (and has been used in many apps like Script#) thus available to typical browsers). How well it would have worked is not the question here, the point is it would have been possible. As such, the claim the browsers alone cannot typically offer is not a correct one. It should be removed. I am being bold and doing it. --soum talk 10:04, 10 January 2008 (UTC)
That is a largely incomprehensible response. I hope you feel better, but it did me (nor WP) no good.
  1. You site no references - all the points you make are entirely your own original research
  2. I'm not harping on - this is the second time I've mentioned this. If you find yourself "sick of dealing with this thing in almost every article", maybe it's because you are wrong to edit in this way, and are swimming against the tide of people trying to improve WP articles for the greater good?
  3. XAML and SVG are one-to-one replaceable in a great many cases, just different enough to be mutually incompatible[4][5].
SVG
 <path d="M10,15c10,10,10,0,40,0c30,0,30,10,40,0q-10,30-40,30q-30,0-40-30"
   stroke="black" fill="red"/>
 <ellipse stroke="black" fill="white" cx="50" cy="40" rx="22" ry="35"/>
 <circle cx="50" cy="40" r="5" stroke="black" fill="red"/>
XAML
 <Path Fill="red" Stroke="black" 
   Data="M10,15c10,10,10,0,40,0c30,0,30,10,40,0q-10,30-40,30q-30,0-40-30"/>
 <Ellipse Height="70" Width="44" Canvas.Top="5" Canvas.Left="28" Fill="white" 
   Stroke="black"/>
 <Ellipse Fill="red" Stroke="black" Width="10" Height="10" Canvas.Top="35" 
   Canvas.Left="45"/>
There is published and reputable criticism of SL on this exact basis,[6][7][8] and it is WP's duty to report on that. Equally there is a point of view that it's a good job MS didn't adopt SVG or they would have started to alter it to make a MS dialect of SVG, as with HTML, CSS and JavaScript at one time.[9] WP must acknowledge and discuss the fact that these discussions are going on, not try to to suppress it, based on anybody's personal research or opinions.
We are a tertiary, or at worst a secondary, source: we report and cite the published facts and the debates, not invent or re-enact them. --Nigelj (talk) 21:40, 10 January 2008 (UTC)
I recommended that this article have a neutral one-sentence mention of this issue, with multiple citations to cover both sides. Leotohill (talk) 22:15, 10 January 2008 (UTC)
@Nigelj: This is not about you alone. This has played out over a very long time, probably before you were even aware this article existed. It even went to an RfC. And if you are trying to improve WP, we are on the same side. I am just against those who edit articles to show any philosophy they do not agree with in a negative light.
Just because you don't comprehend the technicalities do not make them "unnecessary" or "irrelevant". We do not report just for reportings' sake, we have a lot to balance about the info we disseminate: verifiability and neutrality being the most prominent and the latter does mean that if there is wrong criticism, we back it up with refutes. (Needless to say all should be cited). And WP:NOR does not apply to talk pages, I am very well within my rights to write down a thesis here if I want.

(Read on the next few paras if you are interested in details. This is not intended for the article).

SVG does not do what XAML does. In the examples you yourself gave (I am just restricting to the ellipse for discussions sake) what can be done with SVG is restricted by the language itself and the rendering is also dictated by it. However, with XAML, the language doesn't dictate any of it. It only creates objects and sets the properties. The objects dictate what is done, not the language. XAML just converts the markup into this:

Ellipse e = new Ellipse()
            {
                Heigth = 70;
                Width = 44;
                .
                .
                .
            };

Equivalent C# 2.0 code:

Ellipse e = new Ellipse();
e.Height = 70;
e.Width = 44;
e.Canvas.Top = 5;
.
.
.

If there were classes in .NET with name "ellipse" and properties "stroke", "fill", "cx", "cy", "rx", "ry", the SVG markup would have been valid XAML code.

(Now back to the article content)

The point is, it is provably an invalid suggestion that SVG should have been used instead of XAML - because there is no functionality overlap between the two languages (at the technical level, not at the superficial level). Going this deep to discuss in the article is neither suitable nor allowed. But we have a duty (for NPOV's sake) to not promote the wrong suggestion that SVG should have been used in place of XAML (can SVG do UI layout? does it support a potentially unlimited number of UI controls? can it do databinding?). Sure, SL has got (and deserves) criticism for not supporting SVG out-of-the-box and it must be presented. As such, we are left with two choices:
  1. Censor that out for being wrong. Criticise SL for not supporting SVG but do not repeat the suggestion that SVG be used instead of XAML. This was agreed upon as an interim solution to not promote wrong PoVs while giving editors the time to find references.
  1. Mention the criticism but add the refute. This is the preferred solution and was implemented. But you with your infinite wisdom came and deduced that the refute (the netfxharmonics quote) lacks context and since it praises SL and MS, it should go to features section and help promote the wrong suggestion. Why? That was intended as a refute to counteract the wrong opinion being promoted by the bloggers and the tech "pundits". Since the preferred solution wasn't acceptible, I had no choice but to champion the only other solution left.
I propose that it be returned to what it was: Mention the criticism (Ryan Paul et al) and the refs and folow it up with the David Betz comment.--soum talk 05:17, 11 January 2008 (UTC)

[edit] UI Controls in SL 1.0

The text states that "Silverlight 1.0 consists of the core presentation framework, which is responsible for ..., basic UI controls,..."

but later "...there are no UI widgets built in".

This seems to be a self-contradiction, or at least it sounds like one. Leotohill (talk) 21:05, 9 January 2008 (UTC)

Thanks for pointing that out. The first instance is not referring to user interaction widgets but to the graphics (say it is a bitmap, a video, or text or simply colors and geometric shapes) that make up the GUI. Basically its referring to the presentation layer that is responsible for whatever you see on screen - static or dynamic, interactive or not, whatever. I can't really think of a one-word description of it right now. Any suggestions? --soum talk 10:15, 10 January 2008 (UTC)

[edit] Reads Like A Press Release

The tone of this article reads like a press release written by a Microsoft PR drone, and it has seen heavy editing by anonymous users. I'm adding the advertisement tag. Be on the lookout for whitewashing and ad-like copy. Kwertii (talk) 08:45, 9 February 2008 (UTC)

[edit] Silly questions...

This article needs to lower itself to the user and explain a few basics.

  1. What would I use this for? The way I understand it, the program is a new competitor for Flash, which is only needed for a tiny minority of web sites (except to display ads). Are there classic examples of Silverlight sites you can give?
  2. What about security? I see Javascript and very complicated diagrams of features and I think "OMG if I install this all my other browsers will be as rapeme as IE"... is that unfair to think?
  3. Effects on other browsers: does the DRM or some other potential hack vulnerability affect a browser on which it is not installed, and how uninstallable is it?
  4. The update I keep getting offered for Vista is Microsoft Silverlight 1.0 (2/26/8), but the article describes Silverlight 2, formerly 1.1. Why is this? Wnt (talk) 19:44, 18 March 2008 (UTC)
1. (Note: Silverlight refers to SL 2.0 in my answer). Equating SL (or even Flash) with flashy ads is a folly. They both have lot more to offer. With Silverlight, you can develop Rich Internet Applications in .NET languages. That means, you can either develop web sites with snazzy graphics and videos. Or on the other end, use vanilla HTML/CSS for presentation but if you prefer not to use JavaScript, you can use your favorite .NET language to code. Or you can write browser-based Windows Presentation Foundation applications, that give a desktop-application like feel to web apps. Try PopFly or the Silverlight samples at silverlight.net
2. Silverlight is fully managed code, which is inherently more secure than IE's Component Object Model based ActiveX system. Most security problems that plague software aren't possible with managed code. Plus things are snadboxed. Apart from that SL does not let any toolbars or such stuff in. So, in day to day usage, you don't have to worry about security. In fact, it is even more secure than any other plain browser - browsers cannot verify any code that runs and guarantee it wont do any harmful stuff but SL can and refuse to run anything that does.
3. Both intended features (DRM) and unintended (security holes, if one is ever found) will affect all browsers. But content has to be specifically authored to trigger that. And like I said, the likelihood of security holes in SL and their exploitability is much less than the likelihood of exploitability of the browser itself (not just IE, but other as well, until FF moves to Tamarin. As for DRM, its not upto Silverlight to restrict your rights. But to the content providers. If the content providers want to restrict rights, SL will restrict them. If they don't, SL wont. Lobby against content providers to be more permissive. DRM by itself isn't all that bad - couple that with greedy content producers, and you get a rotten taste in your mouth.
4. SL 2.0 is still under development, so it is not available on Windows Update. WU still contains SL 1.0, so thats the version you are getting. You have to explicitly install SL 2.0 from Silverlight.net --soum talk 05:09, 19 March 2008 (UTC)