Discussions

Simple but generic and I had already coded them. Enjoy.

The helper class expects some configuration settings for access rights to the Exchange server, and the location of the server. Otherwise, it will work wihtout changes.

Some of the code comes from ideas borrowed from others. I explain more in my blog post.

phreaks wrote:



Aren't we all scientists here?

Then we have numerous reasons not to believe what scientists say

Of course, we are speaking here of the types of scientists involved in making hypotheses/theories/etc. concerning global warming.

Rossj wrote:

Believe the scientists, don't believe the politically motivated lobby groups funded by petrol companies ...

because scientists don't have agendas or financial backers?

I don't really know the facts either way on this issue either, but I think blind trust in scientists is not a good starting point.

I'd have to agree that isn't a good idea. I thought MS learned something about this naming problem when they finally removed 'Microsoft' (or 'Windows' I can't recall which used to be ubiquitous) from the front of every service name in Server '03 services. I guess those two teams didn't talk.

In terms of learning implementation once you have all the terms and ideas swimming around in your head, I really appreciated Ivor Horton's book on beginning C++. I can't really recall if he tackles the issue directly, or if it just keeps coming up in the examples. In any case, it's a good book if you don't know C++ (and care to).

For myself, and others I have talked with there is usually an epiphany concerning OOP after you have been struggling with the concepts for a while. Just keep trying to apply the ideas. All of the basic patterns in the GOF patterns book are object oriented. Try working through those.

A co-worker of mine is on (or was on) the NDoc beta review team, and received this unfortunate email on the NDoc list earlier today...

"I have decided to discontinue work on NDoc 2.0 and no longer participate in any open-source development work.

The development and release of NDoc 1.3 was a huge amount of work, and by all accounts widely appreciated. Unfortunately, despite the almost ubiquitous use of NDoc, there has been no support for the project from the .Net developer community either financially or by development contributions. Since 1.3 was released, there have been the grand total of eleven donations to the project. In fact, were it not for Oleg Tkachenko’s kind donation of a MS MVP MSDN subscription, I would not even have a copy of VS2005 to work with!

To put this into perspective, if only roughly 1-in-10 of the those who downloaded NDoc had donated the minimum allowable amount of $5 then I could have worked on NDoc 2.0 full-time and it could have been released months ago!  Now, I am not suggesting that this should have occurred, or that anyone owes me anything for the work I have done, rather I am trying to demonstrate that if the community values open-source projects then it should do *something* to support them. MS has for years acknowledged community contributions via the MVP program but there is absolutely no support for community projects.

Once ‘Sandcastle’ is released, it is my belief that it will become the de-facto standard and that NDoc will slowly become a stagnant side-water. This will happen regardless of technical considerations, even if Sandcastle were to be less feature-complete. It's just an inevitable result of MS's 'not-invented-here' mentality, one only has to look at Nant and NUnit to see the effects of MS 'competition'. 

This is not, however,  my only reason for stopping development work - I have a big enough ego to think I could still produce a better product than them

As some of you are aware, there are some in the community who believe that a .Net 2.0 compatible release was theirs by-right and that I should be moving faster – despite the fact that I am but one man working in his spare time...

This came to head in the last week; I have been subjected to an automated mail-bomb attack on both my public mail addresses and the ndoc2 mailing list address. These mails have been extremely offensive and resulted in my ISP temporarily suspending my account because of the traffic volume. This incident has been reported to the local authorities, although I am highly doubtful they will be able to do anything about it.

This has was the ‘last-straw’ and has convinced me that I should withdraw from the community; I’m not prepared to have myself and my family threatened by some lunatic!
 

Kevin

P.S. If anyone wants to take over as admin on the SourceForge NDoc project - contact me. If not, I'll be removing myself in 14 days."

Hmm. The end goal confuses me a bit. Xml is just a text format of brackets and attributes - it is just a representation of data. The interesting things are what we can do with such a simple and transferable representation of data.

Yet, I want to be as far away from working in angle brackets as I can be. If something can be so defined such that it can work as a message to disparate systems, that's great. As a language it is verbose and ugly, as a representation on the wire or in memory it is often overly large.

To compare XML and OO in some way doesn't make much sense to me. XML must always be parsed, and interpreted in some fashion. As the parsers and intepreters move up the complexity value chain it becomes more invisible to the end user and may seem to take on magical properties. But, XML is still just that text representation.

XML can be treated as an object when it is translated into an object system. This doesn't allow us to remove the object system.

Am I missing something in this interpretation?

Why not use a factory?

Seems to be working great now (or for me, not sure which). I am also excited about the tool being offered as it actually works on my x64 machine where other online (and even packaged apps) have failed.

thanks for the link.

Thanks for the feedback. Hmm, not sure why your download speed is so slow.

In any case, this doesn't use sprocs, and is DBMS independent. What it does is use the DataSet information to infer the select statements (in standard dataadapter usage, you must supply the select statement). It then also has objects you can use to provide constraints. All the SQL it writes is SQL-92 compliant, so it can run against any database, and the parameters, etc. are taken care of via the framework's providers - as are the insert/update/delete statements via the usual command builders.

The advantage is that you don't maintain both your dataset structure, and all your adapter/sproc code that works with your schema. If the dataset is up to date, then the commandbuilder can build a statement that will fill/update your dataset.

Does that make sense?