.NET plans and V10
Hi All,
I felt I should post here and also link this post to my previous one on V10 and our plans for the server.
First, sorry for the inconvenience you are experiencing. Counter to a sentiment expressed in the thread, we do understand the server situation and this should have been conveyed in your call with support. I have discussed this with our support manager and he is working to make sure the entire team precisely understands the state of things.
As many of you know we have been working on our server to move it to .NET from Microsoft Java. There are two components to our .NET port, the server and the client; the client is essentially our core CAD system, and the server manages functionality like repository publishing/sharing. Our plan had been to move the server component to .NET first and then follow with the client, however, in the process of moving our server to .NET we identified some different ways of handling the functions the server performs. Some compelling technologies and services have become available since we initially developed our server architecture, and we’ve decided that we can deliver a better solution than we could have by simply moving our current architecture to .NET. As a result, we have shifted our .NET efforts to the client, and then will follow with a new implementation for data sharing and management. The tradeoff, however, is that neither of these projects will be ready by V10.
All data sharing and repository functionality will still be available in V10 but it will continue to use our current architecture, however, we believe that we should be able to deliver better server performance and stability with V10. The reason being that we have found that a lot of server traffic is generated from users signing on who are not using the capabilities of the product that require signing on, such as publishing and sharing a repository or using a server repository. This puts an a unnecessary load on the server that has led to some of the instabilities and server maintenance messages some of you have seen. By changing the default sign on behavior such that, in general, only those needing features such as repository sharing will sign on, server performance and reliability should be improved.. In addition, we are also upgrading our server hardware and monitoring tools which should further help us deliver an improved experience.
In summary, our change in plans with regard to moving our server to .NET will have a positive impact sooner on those aspects of the product that most people touch regularly, while enabling us to pursue a better course of action for delivering more scalable and extensible technologies for data sharing and collaboration. We believe this plan will allow us to deliver the most comprehensive solution and most value to our customers in the least amount of time.
I also want to mention that we have a “local” Team Server product that eliminates the need to connect and sign on to our server via the Internet, so this is also an option. If you feel you can benefit from this, please contact our sales or support teams and we can work with you to evaluate if it will be a good fit for you.
Unfortunately, I can’t give a specific date for the deployment of the new data sharing capabilities or the .NET client port, but they are our top priorities, so we are going to focus on getting them done sooner rather than later. We will provide an update on these projects as they progress.
-Greg
