By the way, for future readers, the bit of drama there was a joke.

All,

I'm really glad to see some momentum picking up.

My Relationship with OpenWITSML
	
	 I work for a start-up MWD company in Houston Texas. We will need  
WITSML capabilities for data export/aggregation in the near future,  
but not immediately. I started this project in order to develop the  
implementation of the client/server in my spare time, and hopefully  
get others involved in pushing it forward. I will work through this  
project as both a user and a developer/architect.

WITSML in the industry

        WITSML, after about 6 or 7 years, is just starting to face  
adoption in the industry. Bigger players like BP, Total, etc are  
currently using proprietary implementations for delivering WITSML  
solutions, with what seems to be very little difficulty. Although  
since each company implements the client/server architecture slightly  
differently, you end up with "dialects" of the protocol, and  
compatibility testing is required. Mid-Size and Smaller companies are  
currently having more difficulty implementing the standard due to  
limited resources, or simply an anti-change attitude. I've worked  
personally with certain companies that refuse to move away from WITS0,  
due to inflexibility, stubbornness, or a lack of vision.

	One thing we need to more clearly define are the goals of the  
project. Currently the goal is a Client API, which will be useful to  
developers, but not the smaller/mid-size shops which are mostly  
"users." In order to push forward adoption we'll need to include a  
built in toolkit for working with and distributing WITSML data. The  
initial goal of this project is not to implement the WITSML Server  
API, but I hope by the time the client has been accomplished that  
there will be enough momentum behind the project to push forward  
server development.

         License selection will become an issue as soon as we're ready  
to distribute the code.

The rest of the email will focus on answering Jonathan's questions.

> So, this project is empty and I can hear the wind whistling through,  
> threatening to carry it away.  Thus is the fate of so many open  
> source projects.

Let's please let this not happen!

> So, here's my outlook on how we should get the ball rolling:
> Agree on a language.  Ken and I were talking about Python and I also  
> suggested Java.  Luckily there is something with the reliability and  
> platform-independence of Java and the semantics of Python: jython.   
> That would be my suggestion in that respect.

There's a lot of use-cases we need to look at and decisions we need to  
make in order to make a decision on a language.

A short list of criterion for language selection:
	* Speed (of the language, ability to code, use-case performance/speed)
	* Readability
	* Reusability
	* Cross-Platform
	* Libraries (SOAP, WSDL, XML, etc)
	* Community/Support

We need to continue developing this list of criterion.

We also need to keep in my that documentation is going to be a big  
help here if we do it. Documenting decisions, code, architecture  
layout, everything will save time, and spur the project along.

> After that, we need to split up the project into reasonable chunks.   
> I'm sure there are a lot of great, advanced ideas on the table but  
> the first thing needed to get people's interest and make sure this  
> thing doesn't fall apart is a layout and a solid base.  SOAP and XML  
> libraries that will be around for the long haul in the language we  
> choose are obviously important in this, as well as a basic version  
> validation system for the files.  At first, the server is more  
> important than the client

+1

We should perhaps start a matrix for comparison of the languages based  
on the above criterion. Speaking of XML/XPath/XQuery capabilities in  
python I'd advocate the LXML libraries. Another major aspect for  
implementation is the WITSML query syntax, which I believe is based on  
a basic XML query.

Another thing we need to look at is available WSDL libraries.

> I've been looking over SOAP, something I haven't messed with  
> before.  After a bit of soul-searching (aka some Google research)  
> I'm still not sure if out SOAP lib will require us to include  
> threading in the server or not.  We definitely need a good  
> understanding of this because SOAP is going to be the base of the  
> client-server module.

> I hope I'm not insulting anyone's intelligence here; I just wanted  
> to lay out what's going on as I see it and start a discussion.

Never worry about insulting anyone. Always speak your mind. Always ask  
questions. I'm really glad you're helping to push this forward.

That's all for now. The ball has started rolling, let's keep it going.

Regards,
Kenneth Miller


>