Future of Team Developer

[EwaldP]

Started in the thread about SP5, a new discussion was started about the future of TD.
I believe this deserves a thread on its own, so I created this new thread and pasted the posts here.

I hope everyone will join in who is interested and has questions regarding the future of Team Developer.

**********************

For me it is the opposite, waiting for the TD6 version which gives us the possibility to consume and create .NET assemblies.

Do you really believe that Unify will be able to implement such a TD version?

To be honest, not in the timeframe Unify has presented at the last DefCon.

Based on past experiences with Gupta and the struggle Unify has to get TD5.1 stable and compatible with TD4.2, the amount of work do be done seems very ambitious.

One thing I'm sure of : TD6 will not be backward compatible with TD5.x.

If Unify chooses not to strictly keep the rule of compatibility, they could focus on core functionality/stability on TD6 and create a really new TD environment.
You can see it happen now: one of the reasons TD5.x timeframe has exceeded the initial plans is the struggle to get the ProfUI's layer 100% compatible (or at least very close to it). This takes a lot of time and resources and it seems Unify has miscalculated the impact of their choice to use ProfUi's as presentation layer.

With .NET (TD6), there is no ProfUi's (if I'm correct, the ProfUi's components are only available on native Windows and not .NET).
As stated in the roadmap they will use Microsoft WPF/Silverlight.

This could mean one thing (my guess) : TD5.5 will be the last native Windows version. TD6 can not be both ProfUi's and WPF compatible. If Unify tries to merge both layers into one TD version, I predict it will be a failure !

So I think Unify has to make a choice : support for both platforms (native Windows and .NET/WPF/Silverlight) or focus on one of them.
Based on the fact Unify has limited resources, I think they should choose to go 100% to .NET and let TD5.5 be the last native Windows version.

As .NET will be our goal platform, TD6 will be the version to wait for.
If Unify does not succeed in getting TD to .NET, I think that would be the last blow for TD !


If my assumptions are incorrect, Unify please correct me.

If TD 6 isn't comaptible to TD 5.x, than this will be a real problem for about 90% of the current Unify Customers. And, to be pragmatic, there is very little chance for Silverlight to get a real share at the users desktop. So why should one use Silverligth if you are on a deadend way again ?
And why do they put this amount of efforts into the ProfUI Stuff, if you can't use it later anymore ? My hope at the moment is, the the guys at Unify getting 5.1 running and release a STABLE 5.2 later on. All what will happen after that is far beyond the Horizont. So migrate now, but don't wait for anything coming in maybe 2-3 Years from now.

Andreas

[EwaldP]

The problem is we TD developers are customed to have nearly 100% compatibility when changing from one TD version to a newer one.
We expect to port applications without major effort and have all features we had in the past.

I believe this assumption has to be abandoned to get TD on the right track for the future.

Looking at other major development environments, the nearly 100% compatibility is not a major issue.
Ever tried to port an application from VB6 to VB.NET ? You will know what I mean.

Unify has to make a choice:
Keep existing customers at a dead end and see in the end the userbase shrinking and later on stop development on TD.
Or, try to give TD a chance to become a choice in a path which has potential future.

The TD5.x path is IMHO a dead end. It is suitable for customers who want UNICODE and nice GUI looks and want minimal effort on porting and see no far future for their build applications (legacy maintenance).
But for a part of the existing customers, they would welcome the new world of .NET.
And what about new customers ? Do they choose to step into TD5 or into a .NET compatible environment?
TD6 has the ambition to become a player in a .NET niche. It will attract old customers who want to expand their product and see a future for it and it could bring new customers who want .NET as platform and see the advantages TD offers (what they might be).

At least for us, TD5 is not considered as destination platform. We don't need UNICODE and the fancy GUI's are only 'nice to haves'.
We need .NET assembly creation and .NET assembly consumption.
So we wait and hope Unify can deliver. When not....

If TD 6 isn't compatible to TD 5.x, than this will be a real problem for about 90% of the current Unify Customers.

Maybe I expressed myself somewhat black and white.
I mean here that TD6 won't be 100% compatible. You can not expect to load TD<6 sources into TD6 and start compiling.
I believe you have to make some (technical/functional) decisions which will cost more effort than porting TD4.2 to TD5.x.

[Didiman]

So this seems to be to become a plattform Discussion. Ok, for that i predict that Win32 and .NET are both dead end. That's because i strongly believe that the future of most if not all applications is the browser. I don't want to use buzzwords like cloud computing or something similar, but in the future ( maybe in 5-10 years ) nearly all needed applications will run in your browser. You may get them from the Internet, from your companys Intranet or simply standalone, but always browser driven. In this case there is simply no need for the developer to use a special .net Environment from which company either.
But, and this is the main point, we live today and we have to deliver todays software. And, to be honest, if Unify cannot attract many new customers for TD ( which is what i'm thinking ), they have to deliver the tools for their existing customers with their existing applications. And for this there is a strong need for a mostly compatible version of TD.
As for the VB migration example, that was and is exactly the reason why most of us are still here using TD. The break between VB and VB.net was a slap at the developers all over. And, to be even more honest, even the different .net - Version are not compatible to each other. If you want to run after M$ and get your work questioned with every new release, than use Visual Studio. We just want to have a stable development environment as long as we have to deliver software for Windows.

[Dave Rabelink]

That's because i strongly believe that the future of most if not all applications is the browser.

I personally dont think so (in near say 5 years future). Past that, who knows

But the reason for Unify to go WPF/Silverlight is to be able to run your apps in the browser (and as client).

In this case there is simply no need for the developer to use a special .net Environment from which company either.

Which environment are you thinking of then ?
(Java excluded)

But, and this is the main point, we live today and we have to deliver todays software. And, to be honest, if Unify cannot attract many new customers for TD ( which is what i'm thinking ), they have to deliver the tools for their existing customers with their existing applications. And for this there is a strong need for a mostly compatible version of TD.

If most customers feel that way, Unify has to decide to drop the plans for TD6 and focus all their resources to ProfUi additions and fixing bugs.
It is a matter of choice here.

[Geert_Schröder]

Hello Dave,

You wrote:
With .NET (TD6), there is no ProfUi's (if I'm correct, the ProfUi's components are only available on native Windows and not .NET).

I guess that's wrong:
Look at ProfUi's under the main menu downloads...second point .NET Controls......

Best Regards
Geert

[Dave Rabelink]

Hello Dave,

You wrote:
With .NET (TD6), there is no ProfUi's (if I'm correct, the ProfUi's components are only available on native Windows and not .NET).

I guess that's wrong:
Look at ProfUi's under the main menu downloads...second point .NET Controls......

Best Regards
Geert

What I understand from the website, the only .NET objects are Elegant Ribbon and Elegant Grid.
The ProfUis product is a MFC library and seems not to have an 1:1 equivalent at .NET side.

[Geert_Schröder]

Hello Dave,

I think that elegant ribbon is not only the ribbon but something like a component suite.

Going the way: main menu "downloads" / ".NET Controls" / Line:
>>Includes documentation and a set of samples demonstrating various features of Elegant Ribbon

I see at the bottom of the description following enumeration:

Controls for the Ribbon and for the Form
............................###############
Advanced Features of Controls
Calendar
Date/Time Picker
Button
Split Button
Drop-Down Button
Toggle Button
Radio Button
Button Group
Text Box
Check Box
Combo Box
Numeric Up-Down
Separator
Label
Panel
Scroll Bars

+ the "Elegant Grid"
------------------------------------------------------
SUM = lots of the needed graphical controls
=======================================

==> In the moment missing (as far as I see):
- Group Box
- List Box
- Tab Frame

Maybe that if unify starts programming the .NET version and brings one by one
control to life that ProfUis might develop what is missing in the meantime.

Important in my eyes:
Formatting in editable controls as data fields and table columns... should realy work reliable.
(Currently an entry in the buglist)
And maybe this is not so easy to program in .NET.
(...but I don't know who is responsible for Unify or ProfUis)


Another thought:
Unicode was added with TD51 (important prerequisite for moving to .NET).
But what about other basic datatypes in .NET as for example
System.Boolean, System.Byte, System.Int32, System.Decimal ...
C#: bool, byte, int, decimal ....
Do you think that we will get new numeric datatypes because compatibility to .NET requires them ?

What about programming elements as :
- enumerations, that might be parameters of functions in included assemblies ?
- name spaces, to distinguish between classes with the same name in different assemblies ?


Geert

[Dave Rabelink]

Geert,

I think when Unify says by utilising .NET assemblies from TD and create them to be used by other development environments, the system has to be CLR compliant.
But as you indicate, there are so many questions now (at least for us developers). For me, I have no idea what Unify will deliver.

I hope Martin Teetz can enlighten us in what their plans are, more on a technical level.
The presentation Martin gave at the DevCon looks very promising, but it lacked technical insight.

For others who have not seen the presentation, you can download the PowerPoint presentation here :
https://samples.tdcommunity.net/index.p ... n_2008.zip

For Martin, I hope you could answer these questions :

- How will TD6 support the CTS, by native .NET types or by pragma's ?
- Will there be a SAL.NET or will the .NET compliance only be achieved by pre-compiling to C# and then to MSIL?
(kind a Sabertooth system)
- Is the current TD5.x presentation layer compatible with the WPF system in TD6? Which components are used, the default MS ones?
- Will TD6 be both compiling to Win32 and .NET? Reading the presentation, there is mentioned special compiler warnings for unsupported .NET features
(like external DLL's and ActiveX code) which indicates this.
- What is meant by TD ASP.NET? A Visual Studio plugin?
- Will there be a completely new IDE ? Will it resemble the current one ?

(for now)

Having seen the roadmap on the DevCon 2007 (where TD6 was targeted for 2009) and the last DevCon 2008 (TD6 targeted for 2010), the plans are there quite some time now. I can not imagine Unify has not thought about how to implement it and it would be a shame if Unify has not already created major parts of it. As stated, at the next DevCon we will see some stuff. I wonder what that could be.

[Martin Teetz]

Dear All,

A few comments on the questions raised in this thread.
We are fully committed to provide a high quality release of Team Developer 5.2. Our Engineering team is working very hard to finalize the functionality and enhancing quality. We are looking to start a beta program for TD 5.2 by the end of March this year.
We will continue to enhance and support Team Developer for the Win32 platform.
For the Team Developer .NET features we are leveraging the Composer Sabertooth technology to create .NET WinForm applications, .NET Web Services and Assemblies.
Non visual TD source can be compiled to become a .NET Assembly or a .NET Web Service.

For the moment this is all I can disclose about future .NET features of Team Developer. At this years devcon we will disclose everything you need to know about creating .NET applications with Team Developer.

Best regards,
Martin Teetz
Director of Product Marketing and Product Management
Gupta Technologies

[Didiman]

Again, there is my benefit if i have to change almost 90% of my existing 1500000 Lines of code to migrate from TD Win32 to TD .NET? If i'm considering doing this, than there are many ways to go to different development plattforms with nearly the same effort. Just as an example, i have written a little tool that converts not-visual SAL Functions very simple to PHP-Functions. So, why don't go directly to an AJAX based environment without having all that M$-Stuff with it. This is just an example, i don't want to start a PHP / AJAX / .NET Debbate, but with Eclipse/Aptana there is such a strong IDE out there for such kind of environment, so i don't need TD to do this.
First priority must be in getting 5.x stable before making developers and customers crazy about some kind of .NET Stuff.

[Dave Rabelink]

Again, there is my benefit if i have to change almost 90% of my existing 1500000 Lines of code to migrate from TD Win32 to TD .NET?

If you don't need .NET, then why porting ?
The benefit of porting to a .NET TD version is : you are on .NET. Utilizing .NET components within your TD application and be able to create .NET components to be used by other .NET applications.

But there is no need to go to .NET if you don't want this. So then, you are right there is no benefit.

The point is, when you do have an application which you want to run under .NET, you are able to by porting it.
It depends if it is worth the effort. If the application has all features required, and the customer/user does not want to invest in the application to get in to .NET, then stick to Win32.

You are also able to get a piece of market in .NET when you have the choice to create new .NET applications using Team Developer.
(Now, this market is 100% sealed off for TD and all TD developers).

Then the question on why use a .NET TD version when there is Visual Studio C# and VB.NET ?
You can ask this question already to yourself in the current situation : why use TD 1,2,3,4,5 when you can use VB6, C++, Java, Delphi etc etc ?
If your answer is : TD is a clear and easy to use environment where I can quickly create applications with compared to other development environments, the answer would also apply to C# and VB.NET. If a SAL.NET TD version has the same benefits in application development and you see a clear advantage to choose TD as development environment, the same consideration which let you choose TD on Win32 now could apply on .NET.

But you also have to consider this : it is getting harder to get TD developers. Even when you have a nice project to create, it is not so obvious anymore you are able to get human resources to get the job done.
A fully compliant .NET TD version gives the opportunity to create parts of your application by other kind of developers. For instance, you can use C# or VB.NET classes (build by your c# developer) and use them in your TD application. So you can mix development environments in your projects, depending on the availability of specific developers. That's the benefit of .NET, being one platform for all languages.

For the Team Developer .NET features we are leveraging the Composer Sabertooth technology to create .NET WinForm applications, .NET Web Services and Assemblies.

So it will be a realtime port from SAL to C# into MSIL?
Does this mean we don't get a new SAL.NET ?

Non visual TD source can be compiled to become a .NET Assembly or a .NET Web Service.

Does this apply for TD6 ?
(my thought->no can't be: as stated in readmap visual presentation is handled in WPF)

If only non-visual code can be created in .NET, it would resemble the limited support in TD for creating ActiveX components.
For a in between TD version like TD5.5 (Tokyo) I accept that, but for TD6 it will be unacceptable.

Martin, I hope you consider getting the community with you in creating a .NET TD version. It would be a waste of time if you present
a .NET TD version which does not fulfill the needs or offers just half-implementations.
A TD6 could be a killer. When implemented right, it could be a real alternative to C# or VB.NET. But it could also be the killer for TD when it does not do what we think it should do.

[randy]

For the Team Developer .NET features we are leveraging the Composer Sabertooth technology to create .NET WinForm applications, .NET Web Services and Assemblies.

So it will be a realtime port from SAL to C# into MSIL?
Does this mean we don't get a new SAL.NET ?

I was told at the devcon that when you want to compile to .NET the sal code is internally migrated to C# using the sabertooth technology and then compiled to MSIL. Therefor Unify has to replace (or give an alternative) all TD controls which are not .NET compatible with prof-ui controls.

[Dave Rabelink]

I was told at the devcon that when you want to compile to .NET the sal code is internally migrated to C# using the sabertooth technology and then compiled to MSIL. Therefor Unify has to replace (or give an alternative) all TD controls which are not .NET compatible with prof-ui controls.

I can understand if you want to reuse TD assemblies in .NET, this way is a quick option. So for a mediate version like 5.5.

But in the Unify roadmap/sneak preview there is clearly indicated that within TD you can use .NET assemblies. Which means TD classes could derive from .NET classes. Which means TD must be .NET compliant and therefore a new SAL.NET environment (type system, namespace system etc etc) must be present.
(I can see no other way, unless someone proves me wrong here).

So the info supplied here about the future TD6 version is confusing. A Sabertooth system will not be able to create WPF/Silverlight applications !
The time until we can see more about .NET features at the DevCon is too far away. At DevCon 2007 it was planned to have a .NET version already. At DevCon2008 we will see it in 2010. Maybe at DevCon2009 we will be presented the year 2011.

(I hope i'm right in thinking Unify does not want to publish more (technical) info about TD6 due to internal reasons and they did start developing TD6 and
did not postpone TD6 due to TD5.1 and TD5.2).