Wikipedia:Articles for deletion/Asynchronous error reporting Source: en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Asynchronous_error_reporting

The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

The result was keep. Per WP:HEY and the withdrawal of the nominator (non-admin closure) Ron Ritzman (talk) 04:29, 24 November 2008 (UTC)[reply]

Asynchronous error reporting (edit | talk | history | protect | delete | links | watch | logs | views) (delete) – (View log)

Google turns up 233 hits, of which 36 unique, with the highest being Wikipedia and mirrors (so not actually unique after all), plus newsgroup postings. No reliable sources. Looks like this fails WP:NEO. Guy (Help!) 20:02, 6 November 2008 (UTC)[reply]

• It was certainly original research, inasmuch as it was a completely novel presentation of an existing concept. I'm not sure what on Earth possessed Davhdavh (talk · contribs) to take some reference documentation, pick one short paragraph out of it that was near the bottom of the page, and create an article on that one small facet of the subject under a completely new name that no-one has ever used for it — especially given that the actual name of the real subject was in the title of the page.

  Anyway, it's fixed now. Feel free to take more sources in hand and expand this meagre stub.

  By the way: You're probably best off redirecting asynchronous error reporting to UltraSPARC IV. It is one of that processor's features. Uncle G (talk) 21:10, 6 November 2008 (UTC)[reply]

• Note: This debate has been included in the list of Computing-related deletion discussions. -- Raven1977 (talk) 04:40, 10 November 2008 (UTC)[reply]

Relisted to generate a more thorough discussion so that consensus may be reached.
Please add new comments below this notice. Thanks, Ron Ritzman (talk) 00:17, 11 November 2008 (UTC)[reply]

Relisted to generate a more thorough discussion so that consensus may be reached.
Please add new comments below this notice. Thanks, –Juliancolton ^{Tropical Cyclone} 02:34, 16 November 2008 (UTC)[reply]

• Undecided. I'm not sure this is really important enough for an article by itself; perhaps it (along with some of the others mentioned on the page) should be described in concurrency pattern instead? JulesH (talk) 22:27, 20 November 2008 (UTC)[reply]

Relisted to generate a more thorough discussion so that consensus may be reached.
Please add new comments below this notice. Thanks, MBisanz ^talk 13:36, 21 November 2008 (UTC)[reply]

• Delete. The topic may be notable, but this article is fairly hopeless. Stifle (talk) 17:13, 21 November 2008 (UTC)[reply]
  • Where does it lack hope? In the stub notice that asks you to expand it? In the now explanatory title? Or in the sources both already used and available as further reading? ☺ Uncle G (talk) 18:32, 21 November 2008 (UTC)[reply]
• Delete Doesn't seem to have any coverage in sources beyond what's already here. Ten Pound Hammer and his otters • ^{(Broken clamshells • Otter chirps • HELP)} 17:17, 21 November 2008 (UTC)[reply]
  • Note the page numbers on the book citations. Several pages in a book don't translate to two paragraphs of encyclopaedia article. This is why this is a stub, and is marked with an appropriate stub template, and why at least one of the books is in the Further reading section of the article. ☺ And that's without taking the MSDN article or any WWW pages there might be on this topic into account. Uncle G (talk) 18:32, 21 November 2008 (UTC)[reply]
• Keep and broaden further. Uncle G already renamed to Event-Based Asynchronous Pattern and rewrote the article accordingly. In my opinion that's still not broad enough, since that's only the callback variant of the client side of asynchronous method invocation. Other common variants are polling (computer science) and blocking at an arbitrary time after the method was started. It's possible to offer all variants in a single implementation, so that the user has the full choice, and that's what .NET Framework does. [1] If the article is kept, I will rename it to asynchronous method invocation and broaden its scope accordingly. This will close a real gap in our coverage, since our (underdeveloped) article on the important Active object design pattern uses the term without any explanation.

I don't know if "keep" is the appropriate !vote in this case; "rename" doesn't seem appropriate because the article in its current state doesn't fit the name I propose. I would have no problem with deletion, since I can still create the new article in that case. But it seems more proper to preserve the history. --Hans Adler (talk) 23:08, 21 November 2008 (UTC)[reply]

• Strong keep. I have extended the article to 7KB by broadening the scope further to the asynchronous pattern, aka asynchronous method invocation (the article's new name), aka IOU pattern. The article now explains why this pattern is important, and it has numerous sources. It's a technical topic, but notability-wise it's definitely not at the lower end of the scale of what we cover. In fact, this is one of the most fundamental and important software design patterns related to concurrency. It was introduced as an article in Dr. Dobb's Journal. By now it is a standard element of Microsoft Windows programming, and therefore the focus of numerous book chapters. --Hans Adler (talk) 23:54, 22 November 2008 (UTC)[reply]
• Keep The article has been renamed and completely rewritten and now has nothing to do with that of 6 November. So I think it should be kept because new version is about an important concept in programming and contains a lot of sources. Ruslik (talk) 15:34, 23 November 2008 (UTC)[reply]

• Keep as Uncle G'd beyond recognition. Guy (Help!) 00:16, 23 November 2008 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.