Open communications in the doldrums

R

Thread Starter

Roger Irwin

The OPC foundation has, in the past, done a reasonable job of 'upping the level' of industrial control interfaces, providing a standard API that is suitable for use by people who are 'above' the device level (production management, quality control etc.). But the OPC standards have many shortcomings. It was originally designed as an API between application and low level device interface, not as a site wide intercommunication protocol. The use of DCOM has allowed it to take on the latter role, albeit with many shortcomings. OPC promised to produce new specifications based on XML that would be more suitable for site/enterprise wide system integration as far back as 1999.

Other organisations have also worked on open protocols for industrial system integration. Some of these of never got out of thier niche markets whilst others seemed to give up in the face of the widespread diffusion of OPC, which is very well supported by both automation manufacturers and third party automation software developers. One competing standard that looked promising was MIMOSA. This had started out by defining database standards and hence SQL interfaces, and like OPC migrated to XML as a concept for improving the interface.

OPC had orginally touted a lot of features, and initially seemed very keen on making some sort of biztalk compliant interface (which worried a lot of us as it did not seemed to be the right sort of interface!). Latterly they have only talked about SOAP. They also talked with MIMOSA and decided to work together on a compatible XML standard. Things were looking positive.

But all that was 2 years ago. Deadlines have come and gone. Announcements have floated by, and in the meantime the actual information available appears to be getting less. In fact the previously published MIMOSA standards have now been made secrect, clearly thier collaboration with OPC has had some effect!

In the meantime we the users are still holding our breath. COM and DCOM are officially passe, but we do not know how or where to invest our time and money in order to go forward! From the information I have managed to extract here and there it would seem that OPC and MIMOSA decided that they had such a mess between them that the needed to start from scratch and produce something sweet and simple, as it should be. Hence also the secrecy, they did not want snippets of the original work to get out as they were allready working on something completely different. Unfortunatly it would seem that 'XML2' has also suffered from comittee bloat and run off the rails as well.

The, out of the blue, arrives IDA (www.ida-group.org). They have come apparently from nowhere with a first rate common sense standard proposal. The basic concept appears to be that of taking the IETF proposed Modbus TCP/IP standard and 'describing' the interfaces with XML, i.e. levering existing technology and standards and making it available in an easy and palatable form to people at an EDP level. That is probably too much a simplification. IDA standards, like OPC, can conceive any underlying transport such as CAN and Profibus, but the higher level interface is defined in a clear simple and concise manner. And it is freely available for download.

So, I thought this might make a good topic of discussion for this group (which has a notorious reputation for heated discussion on comms protocols). Does the IDA group have a chance of filling the void left by the OPC/MIMOSA failure to deliver, or is the OPC on the verge of releasing a world shattering super flexible protocol?
 
R

Ralph Mackiewicz

> The, out of the blue, arrives IDA (www.ida-group.org). They have come
> apparently from nowhere with a first rate common sense standard
> proposal. The basic concept appears to be that of taking the IETF
> proposed Modbus TCP/IP standard and 'describing' the interfaces with
> XML, ....snip....snip....
> So, I thought this might make a good topic of discussion for this
> group (which has a notorious reputation for heated discussion on comms
> protocols). Does the IDA group have a chance of filling the void left
> by the OPC/MIMOSA failure to deliver, or is the OPC on the verge of
> releasing a world shattering super flexible protocol?
I don't think the OPC's objective was to deliver a world shattering super flexible protocol so I don't see how there was a failure (not sure about MIMOSA though).

The public documents available are architectural right now, so its a bit early to tell if IDA is going to be able to deliver a world shattering super flexible protocol. From what I can see, using Modbus TCP for this will not be signficant to current users. If all that modelling stuff is added (Potentially good stuff, by the way. It is what has always been missing from any of the numerous IA protocols du jour commonly used. The model driven approach solves numerous application integration problems) the result will not likely be interoperable with the average Modbus-TCP implementation available today that supports a 16-bit register with a numerical address model unless intervening mapping functions are added that move the integration out of the protocol. That approach can be taken for any protocol. It's called a gateway.

FYI: there is already an international standard IA protocol that
supports robust data models that runs over TCP/IP. But, it is more complex than Modbus-TCP. It's called MMS (ISO9506).

For reasons that you can see in the recent posting that disputed that there was a failure of OPC (PROC: Tag Databases - OnLine (Open source) Specifications ?), I don't think there is demand for a world shattering super flexible protocol. I'm not smart enough to predict the future, but I don't think that there is any significant outcry today for a single protocol that does everything for the IA industry. I'm not even sure that is possible technically, let alone commercially. However, a single approach, particularly a model driven approach, is possible. Go to the Object Management Group ( http://www.omg.org ) and look at their white paper on Model Driven Architecture (MDA) for a description of this concept. IMHO, this is the future.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
R
I have re-visted the MMS stuff and, yes, this is complete and in use and suitable for use by the IA industry. But not adopted.

This is the level of interface I have been waiting for OPC/MIMOSA to come up with for the last two years. But if they never get there (and two years over schedule is a long time by anybodys standard) then will something like MMS or IDA come into mainstream IA like OPC DA has?
 
A little more on iDA. The complete first draft iDA specification is now published on their web site: www.ida-group.org This effort took place because none of the existing fieldbus protocols were sufficiently fast enough AND synchronous in their bus timing to accomplish a distributed synchro motion control network. iDA provides the speed via 100 Mbps Ethernet (as do others) and its synchronization via real-time publish/subscribe protocol.

The exciting news is that the iDA effort is now being lead by Schneider Electric as their successor to Modbus/TCP for real-time automation networks. Rather than develop their own "yet another protocol", Schneider has elected to back the previous user-led iDA effort. One of the most significant benefits of iDA is their object model for communications. This object model is based on IEC 61499, the same basic specification for function blocks on which IEC 61804 is basing their work. iDA does not specify their object
model, only the time-critical communications with automation objects. Good work with the right objective -- in my own opinion.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================
 
R
> I don't think the OPC's objective was to deliver a world shattering super flexible protocol so I don't see how there was a failure (not sure about MIMOSA though).

The world shattering were my words, but look back at thier press releases and perhaps I was not far off;-) However, the intention was to make a standard that could work accross enterprise networks in an open and flexible manner, something their present standards fall far short of and for no fundamental reason.

> The public documents available are architectural right now, so its a bit early to tell if IDA is going to be able to deliver a world shattering super flexible protocol.

I think the IDA communications section when read in conjuction with modbus tcp/ip is a pretty complete document, including XML schema and examples as to how we can define data to be transferred over modbus TCP/IP (I was reffering to the comms section and not the whole IDA model, but as is probably clear, I am also playing the devils advocate;-))

> FYI: there is already an international standard IA protocol that
> supports robust data models that runs over TCP/IP. But, it is more complex than Modbus-TCP. It's called MMS (ISO9506).

I keep running into this, I would appreciate further comments as I can never understand wether it is still in experimental phase or has been ratified. Opening up the argument what do other people think of this approach as an enterprise or intersystem protocol.

>I'm not smart enough to predict the future, but I don't think that there is any significant outcry today for a single protocol that does everything for the IA industry. I'm not even sure that is possible technically, let alone commercially.

I don't think a single protocol is either viable or desirable for all IA. In particular at a local level protocols such as CAN and Profibus DP serve requirements that are far removed from e.g. XML. OPC is still better than XML for the type of applications it was originally intended for such as interfacing a PC based SCADA to PLC's.

BUT, we do need a common protocol for exchanging between subsytems and from governing/monitoring systems to underlying subsystems. There are allready protocolls capable fo doing the data transfers, but we need a standard way to define the connections and have a common API. OPC has demonstrated the advantages of this.
 
P

Peter Whalley

Hi Roger,

A few (rather cynical) observations:

1. the IDA Group seems to be completely dominated by Europeans. This probably means that the US will totally ignore the standard however useful
it is.

2. whilst the standard is available for download, use of the standard requires permission in writing from the publisher (ie IDA Group e. V.) No information is given as to the circumstances under which such permission would be given or if any fees would apply or if permission could
subsequently be revoke of if use of the standard might infringe other peoples intellectual property rights.

3. when I try to download the membership application form my browser gives me an Error 404 (page not found) in German. Makes it hard to join or even to find out what the joining fees are.

4. The specification runs to some 435 pages which on the surface looks very complex and hard to understand. Hardly likely to encourage it's use.

Regards

Peter Whalley

Magenta Communications Pty Ltd
Melbourne, VIC, Australia
e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending
 
I have been spending a little time at the IDA web site and while it looks interesting I see no language regarding the licensing of the technology. I also then spent some time last night at the patent office (web site that is) searching for patents from the member companies. There are a number of patents that cover many of the technological virtues that IDA seems to extol.

Given that the board is made up of four or five vendors each with numerous patents that cover many of technologies that IDA seems to utilize it makes me wonder.

Now if this were an environment where patents were used solely as defense then I would say no problem. But we know better now that some see fit to use them like weapons. So I ask should initiatives like IDA make a clear statement upfront regarding the goals and requirements of their membership that precludes any member from surfacing a submarine patent once a body of products have been developed?

Thoughts any one.

Moderator, Surprise me by not censoring a response that clearly hits on such a touchy area.

(One person's touchy subject is all in a day's work for others. Surprise us all and sign your name next time... :) --The moderator )
 
History from one who lived it, to those who might be doomed to repeat it.

MMS is an ISO standard that was created as a "companion standard" during the MAP craze of the early 1980's. The model for MMS was the Modbus set of commands. The MMS standard is actually constructed in an early object notation to isolate the commands from the actual underlying hardware of the controller. In this aspect, MMS was targeted to the same level as OPC/DA about 10 years previous to OPC.

FMS is the Application Layer of Profibus, and is an adaptation of MMS missing only the commands related to computer-to-computer transfers not
needed in computer-to-PLC transfers. FMS served as the model for the Foundation Fieldbus Application Layer during its development.

Since both Profibus and Foundation Fieldbus are widely deployed today, and both include FMS, it's not too difficult to find how MMS fits into
industrial automation.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================

-----Original Message-----
From: Roger Irwin

...snip

> FYI: there is already an international standard IA protocol that
> supports robust data models that runs over TCP/IP. But, it is more complex
than Modbus-TCP. It's called MMS (ISO9506).

I keep running into this, I would appreciate further comments as I can never
understand wether it is still in experimental phase or has been ratified.
Opening up the argument what do other people think of this approach as an
enterprise or intersystem protocol.

..snip
 
Peter,
The development of the iDA specification took about the same time as development of the Foundation Fieldbus specification -- about 1-1/2 years. During most of the development time, the entire team was German. All of the team members I met also spoke English quite well. One of the turning points in the iDA project was the influx of Schneider Electric in late 2001. This
had the effect of making the project take longer, but subjected iDA to a more thorough review. Schneider has announced that iDA is the logical
evolution for their own real-time networks to augment and supercede Modbus/TCP.

One of the key elements of iDA is their use of NDDS middleware for device synchronisation using real-time publish/subscribe. This is needed for
distributed motion controllers to perform coordinated multi-axis machine control. It is the same mechanism as used by Foundation Fieldbus in a less time-demanding application (process control). NDDS comes from RTI www.rti.com that makes it available on almost all computing platforms. RTI has submitted the mechanism of NDDS to the IETF as a pre-standards document.
As far as I know, it is the first time any real-time documents have been proposed to the IETF, the governing body of the Internet.

Siemens has been using Simatic Ethernet for a long time, but it is not compatible with Profibus. PROFInet uses Ethernet, but it is not for real-time applications. Recently, Siemens has expressed interest in iDA to have standard a real-time protocol that works with the Ethernet interfaces they have had in their PLCs for a long time.

I see a bright future for iDA if Schneider and Siemens build product for it.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================
 
R

Ralph Mackiewicz

> I have re-visted the MMS stuff and, yes, this is complete and in use
> and suitable for use by the IA industry. But not adopted.

Actually, it is not widely adopted but it is adopted in some niche applications. There are installations using MMS and there are
occassional new installations in IA as well, usually involving CNC equipment. It is much more widely adopted in the utility industry.

> This is the level of interface I have been waiting for OPC/MIMOSA
> to come up with for the last two years. But if they never get
> there (and two years over schedule is a long time by anybodys
> standard) then will something like MMS or IDA come into
> mainstream IA like OPC DA has?

Good Question. I have no idea. It seems to me that the success of a new technology in this industry (as with the vast majority of
industries) is very dependent on marketing. I think one of the reasons for the success of things like OPC, Profibus, DeviceNet, etc. is the companies that back these technologies with competitive products. MMS was originally saddled with the baggage of the IEEE 802.4 broadband token bus of MAP that GM was pushing. Once support for this broadband stuff went away, there weren't enough vendors supporting MMS on Ethernet-TCP/IP for it to become widely adopted. And, after sinking literally millions of dollars into broadband modem developments, most of these vendors simply dropped the products completely (with a few exceptions) throwing the good out with the bad. There was also the issue of complexity. At the time, computing power and memory were very expensive. Today, the complexity of MMS is not that much of a technical issue anymore. However, most of the IA vendors are into pushing their proprietary developments into
standards, not pushing standards into their developments and most users don't seem to mind that approach. IDA does have some vendor support behind it so maybe it will work out for them. But I don't think you will see Schneider competitors jumping on that band wagon too quickly.

It's about time that model driven approaches are being brought to IA.

> The world shattering were my words, but look back at thier press
> releases and perhaps I was not far off;-) However, the intention
> was to make a standard that could work accross enterprise networks
> in an open and flexible manner, something their present standards
> fall far short of and for no fundamental reason.

The difference is that OPC was never intended to be a protocol. It started as an API. Their XML protocol based work is a recent development.

> I don't think a single protocol is either viable or desirable for
> all IA. In particular at a local level protocols such as CAN and
> Profibus DP serve requirements that are far removed from e.g. XML.
> OPC is still better than XML for the type of applications it was
> originally intended for such as interfacing a PC based SCADA to
> PLC's.

Actually, it was originally intended as an API that would isolate the applications (e.g. PC based SCADA) from the protocol drivers. I don't
think it was ever intended as a protocol except by some early advocates who claimed you could use the DCOM protocol for this purpose (which didn't work too well I might add).

> BUT, we do need a common protocol for exchanging between subsytems
> and from governing/monitoring systems to underlying subsystems.
> There are allready protocolls capable fo doing the data transfers,
> but we need a standard way to define the connections and have a
> common API. OPC has demonstrated the advantages of this.

OPC has certainly demonstrated the advantages of a standardized API. No question. It has made many of the protocol integration issues simply go away for Windows based systems. IMHO, OPC is one reason for the success of the Wintel platform in IA. By using an API to isolate an application from the hassle of dealing with a specific protocol from within that application, OPC has reduced some of the impetus for a common data exchange protocol. Ironic, isn't it?

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
This is an excellent and timely issue, especially since Schneider is part of the iDA management group. If you remember, Schneider is the company that invented Modbus/TCP and placed the specification in the public domain by publishing it on their www.Modcon.com web site. Then in 2000 they filed suit against OPTO 22 for infringement of some of their patents. OPTO 22
used Modbus/TCP.

I have been assured by Schneider and Jetter AG, two of the vendor companies in iDA that they wish iDA to become accepted and do not want the patent
issue to become a problem. RTI is the company that has helped write the iDA specification in English and has bound in the real-time publish/subscribe RTPS protocol into iDA. I have seen the RTI submission to the IETF in 2001 that placed the RTPS algorithms into the public domain as required by the IETF for a standard.

This makes me feel good about iDA, but in this patent game, you never know. The technology of iDA belongs to the iDA Group, which is chartered in Germany as a "club". The only way to assure your own protection is by contract protecting you even in case the ownership passes to another party.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================
 
I have started and abandoned a few replies on this topic, And maybe this one will join the others, but we'll see! ;->

I went through the website, drug myself through about as much of the pdf file as I could stand, and although I think it is a noble effort, I just
don't see it going anywhere.

It appears that they intend to freely license everything, as they make some claim to following the open source model, etc. Now, we have all
heard the "Open Platform" mantra from just about every vendor, and they all turned out to be bogus.

My reaction, though, is "So what?". It appears to be a middleware sitting on top of Modbus/TCP. This makes sense, since Schneider is one of the
"founding members". The problem is that in the global market, Schneider is a distant fourth. Siemens will never let go of ProfiBus, and Omron and Rockwell are both backing Ethernet/IP through the ODVA group. I don't expect to see any of the top 3 divert any energy into supporting something
that is basically designed to bring Schneider back into the "upper group", so to speak. And without a clear statement of licensing intentions, it would be foolish of any of those three to start building technology around it.

I am sure it is a noble effort, but unless you are already dedicated to using Schneider's (Modicon) controllers, I wouldn't expect to see Siemens, Omron, or Allen Bradley rushing to offer their own implementation of IDA.

Just my thoughts....

--Joe Jansen
 
C
That is a grave concern, and I am not anonymous :^)
What's more, on all these industry consortia and
the OPC foundation specifically, the member list
gives me pause to reflect that depending on these
folks for _Open anything_, is closely akin to
depending on OPEC for alternative energy.
It's simply not what they do, in thought, word, or
deed.

What then, makes them qualified or even credible?

PS The submarine patents issues pervades OPC, XML and SOAP.

Regards

cww
 
R
I hadn't noticed the patent and copyright issues. Well spotted. Also, while the full spec does run to 500 pages, it is quite a comprehensive set of guidelines that do not need (indeed they do not suggest) be applied in paralell as an all or nothing solution.

The communications section is around 100 or so pages, and like I pointed out appears primarily interested in formalising data types and message packets and defineing a way to describe communications implemented in modbus TCP/IP, basically making it a more palatable and comprehensive solution.

Now to change tack, I would like to explain WHY I (and probably many others) need to break out of the OPC DA 2 stranglehold.

Like many people in this group a large amount of my work involves interfacing production systems to EDP systems. Following a peiod of uncertaintity in the wake of the .net hype, there has been a significant shift towards Java on the part of corporate EDP users (for backend servers, not desktops), and with it often a desire to use Linux/Unix solutions for back end apps. Yes there are alternatives to OPC, but nothing like it in terms of product support, whilst using OPC means putting in Windows boxes to house OPC servers and Java gateways/adapters. It is a silly situation and we need a way out.

Whilst windows remains the preodominant platform in the automation industry, IA needs a protocol that can bridge between the IA world and the EDP world, and clearly this must a protocol supported by BOTH sides.
 
A
"These folks"?

There are 300 members in the OPC foundation. There are major automation vendors, small automation vendors, single person consultancies, and universities that are members, and they're spread out over the entire world. Heck, if you want to sign up a group of open source people, I'm sure they wouldn't mind if you wanted to fork over the $500 non-profit association fee. You're always saying that there are plenty of folks that want to have more open control, right? Get 50 friends together, $10 a pop, and contribute your input.

The 50-odd corporate members (those the OPC foundation says can "create and shape the technology") that have their products listed on the OPCFoundation.org website are listed at
http://www.opcfoundation.org/05_products/05_self_cert.asp.

Once again, they range from vendors large to small covering the entire globe.

Painting everyone in the OPC Foundation (which doesn't include my company, by the way) with a big proprietary-monopolistic brush is unfair. Implying that they're all out to screw the customer by making them pay more for proprietary things is unwarranted and hurtful.

Alex Pavloff - [email protected]
Eason Technology -- www.eason.com
 
M

Mark Hensley (Kepware)

Hi Alex,

Kepware is one of those small companies listed in the link you provided and I would like to think we aren't out to "screw" anyone. Pardon my French.

Constantly I hear how if only everything was open source everyone one would get everything they ever wanted instantly. Specifically when it comes to product enhancements or fixes. So here sits little Kepware (evil provider of windows software), along comes a customer with a problem. This happen today by the way. Customer "I'm seeing an issue in your GE Ethernet driver when reding PLC status data, can you check it out?" Our response contrary to our the so called "Screw'em" goal of windows based vendors, was immediately grab our GE PLCs hook up a couple of them, verify the problem, make a fix, test it, send it to the customer. All in the span of about 4 hours (testing takes a little time).

Now at what point in this story did I screw the customer. The new driver will be part of the next release of our server which is FREELY available from our web site at no cost for the upgrade. If the answer from some of our fellow list members is that I charged them for the driver in the first place then I'm sorry. Last time I checked I didn't hear any bells ringing that indicated it was time to go eat the state sponsored free lunch.

Sorry for the soap boxing but its rare that anyone gives us little guys any credit like you have done Alex and I want to thank you for that.

Mark Hensley
Kepware Technologies
( We make software, and we sell it, EVIL :) )
(If you run our software backwards you hear devil music).

Sorry its been a long week.
 
C
Hi Alex

I don't think you read what I wrote. You're putting words in my mouth again.

It would be impossible to recruit even 5 people who would join this MS fan club from among my friends. To recruit 5 people to write an Open
replacement would be far more constructive, since you simply can't build something Open that's based on closed, proprietary, perhaps patented, MS intellectual property. And, it wouldn't stand a snowball's chance of MS or large vendor adoption anyway.

The best that a membership could get me would be the opportunity to build compromised solutions
that further encourage the monopoly and friends.

And although I don't recall implying that anyone
was screwing anyone, (I haven't been to a meeting
so I don't know what they do there) it's a safe
bet they are all MS users and thus supporters of
the monopoly, willing or not. Is that unfair?
I leave it to the reader as to whether the best
interests of customers are served by more lock-in.
It's sorta like Henry Ford said: "They can have any color they want, as long as it's black" But I do apologize to the non-corporate members since they can't, apparently "create and shape the technology".

Regards

cww
 
R

Ralph Mackiewicz

> Whilst windows remains the preodominant platform in the automation
> industry, IA needs a protocol that can bridge between the IA world and
> the EDP world, and clearly this must a protocol supported by BOTH
> sides.

If that is true, then you can give up on any solution based on Modbus. I don't see the EDP/IT world moving to Modbus. An attempt to put it into this environment would likely be met with stiff
resistance from the IT world. The IA market does not have much leverage on the bigger (much bigger) IT market. A more practical approach is the is to leverage the technologies that the IT world has already embraced.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
A
Curt Wuollet wrote:
> It would be impossible to recruit
> even 5 people who would join this MS
> fan club from among my friends.
>
> To recruit 5 people to write an Open
> replacement would be far more constructive,
> since you simply can't build something Open
> that's based on closed, proprietary, perhaps
> patented, MS intellectual property.

Step back. OPC provides a way for any program, via a common API, to access anyone elses data. So companies like Kepware, Software Toolbox, and various automation vendors, large and small, write OPC servers which handle all the nitty gritty details of talking to devices. OPC _could_ be used as a protocol (via DCOM), but its not recommended. The OPC server normally talks
to the device in their preferred format, whether it be serial, ethernet, or something else. End result -- the accessing of data is decoupled from the use of the data. Vendors writing HMI and SCADA systems don't have to write drivers anymore, they can buy them from other vendors. Heck, if you decide that you don't like your OPC server, they're absolutely nothing to stop you
from getting one from a completely different vendor and using it with nothing more than a few lines of code changes.

These OPC servers are built on COM. COM objects can be accessed from any language from tools written by any vendor. The Borland and Metroworks, MinGW, and most all windows-based compilers in a variety of languages all support writing and accessing COM objects. The underpinnings of COM objects themselves are based completely on C++ vtables. For an extremely
good guide to COM, I recommend picking up "Essential COM", by Don Box.

I tell you this because you don't appear to have any idea what technology OPC is actually based on.

If you want to create an open replacement to it though, go right ahead. Until its done though, I think most people will just use the technology that already exists and is supported

> The best that a membership could get me would
> be the opportunity to build compromised solutions
> that further encourage the monopoly and friends...

<snip>

And we're back to anti-Microsoft. I'm not going to respond to that, because I think I've done it around 30 times before.

Alex Pavloff - [email protected]
Eason Technology -- www.eason.com
 
Top