RTC Forums

Hello!

Are there any plans for new version? We are in 2019.Q3 already and every year there were quarterly updates - but not this year.
Any reason for that?

Please, read the "RealThinClient SDK v9.50 (2019.Q1)" topic in the "Downloads" area. There are at least two replies in that post to explain our short-term and long-term plans for RTC SDK.

I have read the statements already some time ago. But this is not really answering my question. What is "short-term" for you - days, weeks, month?
Also I don't understand when you write you will split the product into parts. More and more functions will be removed from the product we all bought -> Legacy.

You also wrote new platforms will be not supported? What are new platforms for you? You will concentrate on Windows Server components only. But what about the clients? A server without clients makes no sense or should your customers look for other client solutions to connect to your server solution? Sounds very strange to me.
And clients are MOBILE today - and not only Windows.

My main question is will you support all platforms which Delphi 10.x are supporting now?
This is the reason why I use Delphi and your components to connect from any device to a server.
  - Windows 32bit
  - Windows 64bit
  - macOS 32bit
  - macOS 64bit
  - iOS 32bit
  - iOS 64bit
  - Android 32bit
  - Android 64bit (soon)
  - Linux

My apps are using your technology to communicate with each other.
This main components are used (I already removed all legacy components):
Server:
  - TRtcHttpServer
  - TRtcServerModule
  - TRtcFunctionGroup
  - TRtcFunction
  - TRtcHttpClient
  - TRtcClientModule
  - TRtcDataset
  - TRtcValue
  - TRtcArray
Client:
  - TRtcHttpClient
  - TRtcClientModule
  - TRtcDataset
  - TRtcValue
  - TRtcArray

I hope you get my point. Just want to continue in the future with your products and expect also full support.

Short-Term basically means "until further notice". There is NO fixed time-frame, but it's definitely measured in months and could even be longer than a year, since it depends entirely on our progress with the new library (see below).

The complete table of all IDEs & Target Platforms supported by the RealThinClient SDK v9.50 is available HERE (click) (https://rtc.teppi.net/details/). We plan to continue supporting all the combinations of IDEs and target platforms listed in that table, but ... we do NOT plan to add support for ANY platforms NOT already listed in that table. Also, because we have NO control over future Delphi updates, we can NOT ensure that ALL platforms listed there would continue being supported in all future Delphi releases. In other words, should Embarcadero introduce changes to their RTL which would break compatibility with the current RTC SDK implementation, we might actually reduce the number of supported platforms in future Delphi versions.

Long-term, we will ONLY be supporting Windows (32-bit and 64-bit) as our target platform. We are now working on a new light-weight Delphi library, which is being designed and implemented from the ground-up (not based on the RTC SDK), focused entirely on building high-performance native Windows Servers (32-bit and 64-bit) to host pure Web-Based solutions (HTTP/S), utilizing Web Browsers as our target Clients. Some very basic Client-side functionality will most likely be implemented in the new library, since we'll need that for stress-testing the Server, but it would also be for Windows ONLY and would ONLY include very basic HTTP/S request and response handling. We are still at the early design and development phase of this new library, so ... don't hold your breath.

We will be making a public announcement if there are any more news worth sharing.

> My main question is will you support all platforms which Delphi 10.x are supporting now?

No. We won't .
We are going to support Windows platforms only , in the long run.

The reason #1:
99% of our revenue comes from Windows developers
and dropping support of other platforms (iOS/Android/OSX/and any)
will save us 90% of testing and supporting cost.

The reason #2:
We highly doubt that Delphi can survive as a mulitplatform development IDE.
You know what happend to Kylix , what happend to Delphi .Net .
They are just gone.

We cannot invest on supporting a certain platform,
when we can't believe Delphi would continue supporting it.

>But what about the clients?
>should your customers look for other client solutions
> to connect to your server solution?

Yes, you should start developing your client apps with HTML/javascript ASAP.
Or at least you'd better start researching about it.
It works on all platforms including iOS,Android,Linux,
and I believe that huge companies like Google,Apple,Microsoft,Facebook
all will continue investing on that platform. There's a promised future.

We stopped developing Desktop application with Delphi about 10 years ago
and the transition took us years, but I never regret that.
We now focus on develping Web (HTML/javascript) client applications.

>What is "short-term" for you - days, weeks, month?

Basically we won't add any changes to RTC.
It's now in "maintainance mode", fixed and stable.

You don't have to worry about the risk  that
we give up the entire software component business one day and run away suddenly.
We are here for years to help you if you might have difficulty using your current library features,

We will continue investing on a Delphi Library for server development
although we know Delphi developer base is small and shrinking,
because we still belive Delphi is one of the best language for developing Windows server application
with its native Windows API access and high performance .

Cannot agree more!


I can definitely say that i agree! HTML/JS/CSS and a good Pascal => JS compiler. Rocks.
I can recommend to have a look at DWScript.

I will, however, still keep one (bigger) Delphi VCL+DX+RTC application.

Regards and goodspeed.

/D

Hello!

I just read your product description again and it is stated as:
RealThinClient SDK
- Delphi components for building reliable cross-platform HTTP(S) Clients, Servers, Routers, Proxies, Load Balancers & more …
- Some Features: Cross-Platform - Target Windows, Mac OSX, iOS & Android from a single code-base
You referred to an list of supported platforms:
- Win 32/64, macOS 32, iOS 32/64, Android 32

BUT, macOS 32 will be legacy with new version of macOS (this fall) and also Android 32 is already legacy.
So you support now only 2 platforms (Windows and iOS) out of 5 (Windows, macOS, iOS, Android, Linux).
This I would not call "Cross-Platform"..  ::)

Don't understand me wrong - I LOVE your product - therefore I don't want to loose it.
If you don't want to be "Cross Platform" anymore . you have to write this also in your advertisements.
Otherwise please make your "core" functions available for all supported platforms (web server / client) - PLEASE!

Greetings
 

Man: "Why are you howling at the Moon?"
Wolf: "I'm greeting the Wolf on the Moon."
Man: "You mean ... the Man on the Moon?"
Wolf: "No. The Wolf on the Moon. Why? Do you think there's a Man on the Moon, too?"

Using DWScript will waste more time. It is enough to use RtcScript. The main function is still handled in the custom function. Just call it through RtcScript. I packaged a webpascal tool to develop the web project. The effect is good. You can check it out at webpascal.com .

Hi,

what kind of developers ?
Developers using RTC ?
You save 90% of testing, that's fine for you, but Delphi RTC Developers (Android)?
You stopped Delphi about 10 years.
Why did you buy this real great Software RTC for Delphi ?

Regards

https://rtc.teppi.net/aboutus/

<quote>
Teppi Technology is a Tokyo Japan based independent software developing company, specializing in document management systems , file server search systems and remote access solutions that works with Windows file servers. Teppi Technology was founded in 2000, released the first version of its flagship packaged software “FileBlog” in July, 2007. Since then Teppi Technology has sold products to wide range of enterprise customers with high volume Windows file servers.

We, Teppi Technology have been using RealThinClient SDK since 2008. We began developing web server application with PHP first. But soon we found our enterprise customers suffer from poor performance and unstability. Since then, RTC SDK helped us a lot with its rock solid performance.
</quote>

IOW, Teppi has been using the RealThinClient SDK with Delphi since 2008 (and are still using it today) to develop "FileBlog (https://www.teppi.com/)", a pure web-based remote file management system for Windows file servers.

Hi to all,
  in a previous post you mentioned

"The good news is that using units and components from the "Legacy" folder is NOT going to leave you stranded when the next RTC SDK update comes out. Even though we do NOT plan to continue offering support for "Legacy" units or components, anyone who is already using these units and/or components should NOT have to worry about keeping that code compatible with future RTC SDK versions. In fact, as long as Embarcadero does NOT introduce some compatibility breaking changes to Delphi, that "Legacy" code should continue working as-is, without any modifications."

This is very different from what you are suggesting now, and in my opinion is also unethical. We are currenlty using your components in a very large and complicated project that is also cross platform. We support natively Windows, MacOS, Linux, Android and iOS and we want to keep it that way. I strogly dissagree with the opinion that every client should be a Browser. Our software is a POS system for the hospitallity market and we need to have access to undelying hardware like NFC readers, serial ports, Bluetooth devices etc. For this and many other reasons the Browser is not a viable solution for us.

We chose and payed for RTC exactly because it is native code and cross platform. The complete rewriting of the client code as suggested (according to what Teppi did), is a very lightheaded approach to say the least.

I agree on that adding new features is not an option for you, but there must be updates covering all the supported platforms and their feature releases. We have succesfully compiled RTC for macOS64, and are waiting to see what will happen when the new compiler for Android64 comes out. Hopefully it will compile as is, without any changes.

Last but not least, you say that you will not support any future breaking changes in the RTL. This is also an unacceptable approach for a product that is heavily dependent on RTC. If your plans are to leave us stranded for future Delphi versions, then you should consider making RTC open source, so that there is a viable future for us and all the others that are using it...

I invite all active RTC users to state their thoughts on this...

Stefanos

"You can have all the money in the world, but if you are not a moral and ethical person, you really have nothing..." - Henry Kravis

RTC SDK is a mature product. We won't update it unless we find some critical bug about it .
I understand your disappointment, but basically, we won't invest on this product any more.

Developing and maintaining a software product cost you a lot.
DeltaSoft failed to get enough financial aid from you customers
and eventually gave up its business last year,
when RealThinClient was on the virge of a "sudden death".

I personally think you're lucky that you still have this forum running.

Teppi Technology bought the intellectual property of RTC from DeltaSoft
because we were making enough revenue from our software product based on RTC
and wanted to hedge the risk of losing technical support on RTC .

Imagine how much we paid for RTC please,
and I beg you understand our patience and contribution
on prolonging the life of RTC.

If you really want long term cross platform support about RTC,
you should buy the modification / development right from us
and develop yourself from the source code.
Or, you'd better switch to other product.

I think it is pretty fair and ethical of us that we give you enough time to prepare .
Isn't it ?

Hi Mr. Okada, and thank you for your reply. These are my thoughts:

"Teppi Technology bought the intellectual property of RTC from DeltaSoft
because we were making enough revenue from our software product based on RTC
and wanted to hedge the risk of losing technical support on RTC ."

We are on the same page here, we all want to have our software running smoothly for as long as possible.

"Imagine how much we paid for RTC please,
and I beg you understand our patience and contribution
on prolonging the life of RTC."

I agree with you on the cost, but you are not doing me a favor,
i am paying too, i am on subscription until August 2020.
When you renewed my subscription on August 2018,
you forgot to mention that you would stop adding features,
support new platforms or new Delphi versions. Not to mention
the huge cost, on money and time, of switching to another framework.

"If you really want long term cross platform support about RTC,
you should buy the modification / development right from us
and develop yourself from the source code."

I could do this even without buying the modification / development
right, but the reality is that it is almost impossible for someone apart from
Daniel to support such huge project. For the very same reason you decided to buy him...


"I think it is pretty fair and ethical of us that we give you enough time to prepare .
Isn't it ?"

No it is NOT, since

a) you got money from RTC's customer base (and me), promising full support
    of the product and decided at some point that "we won't invest on this product any more"

b) you are STILL selling from your site, subscription plans,
    at the same prices as you did when the product was fully supported

c) you have hidden your real intentions until recently (August 2019)
    in order to get back as much money as possible of your initial investment



Stefanos


Ethics is knowing the difference between what you have a right to do and what is right to do. - Potter Stewart

Copy/Paste of my last two posts in the "RTC SDK Downloads" area ...

QUOTE from June 28, 2019, 11:50:22 AM »
   
If you are wondering what's happening, here's an update to our short-term and long-term plans ...

What is our short-term plan?

RTC SDK (v9.50) is now in maintenance mode, which means that we plan to continue providing bug-fixes and/or updates needed to keep the code from the "Lib" folder (NOT the "Legacy" folder) working "as-is" with the latest Delphi version, but there are no plans to add support for new platforms or new features.

What is our long-term plan?

We have started designing a NEW light-weight Delphi library for building stand-alone Windows HTTP/S Servers using Web Browsers as Clients. This new library is being designed from the ground-up, with the goal to simplify building robust and reliable Windows-based HTTP/S Servers (no plans for Client-side features or any other platforms than Windows), to fully utilize the new HTTP/2 protocol (in addition to HTTP/1.1) and be flexible enough to allow extensions needed to support future HTTP versions, like the recently proposed HTTP/3 standard (which uses UDP instead of TCP/IP at the lowest protocol layer).

We are still in the early design phase, so please don't ask about a possible feature set, or the estimated release date, or even about the price. We plan to continue maintaining the RTC SDK "as-is", for as long as we are using it in our flagship product "FileBlog", but ... if this new library is finished (with a strong emphasis on the "if" part) and we are satisfied with the results (with a strong emphasis on the "satisfied" part), we will be using it as a replacement for the RTC SDK in our flagship product "FileBlog". And if that happens (currently, that is still a big "if"), it is quite possible that the entire RTC SDK would be discontinued in favor of this new library.

But ... there's a long road from design to a final product and we are still at the very beginning, so ... nothing is set in stone yet.

QUOTE from July 05, 2019, 10:00:43 AM »

I've changed my post above to use the word "library" instead of "component set", because I'm leaning more and more towards a pure code-based approach than the "component set" approach used in the RTC SDK. Also, to make full use of new language features (like generics and anonymous methods), without having to include several different implementations for compilers which don't support these new language features (because we want this new library to be light-weight and NOT another 250K LOC monster like the RTC SDK is today), we will ONLY be supporting Delphi 10 and later. There are NO plans to support older Delphi versions or alternative compilers like FPC.

In a nutshell, this new library would:
- only support Delphi 10 and later versions
- only support 32-bit and 64-bit Windows platforms
- only include features required for building stand-alone HTTP/S Servers, using Web Browsers as Clients
- start with full support for HTTP/1.1 and HTTP/2 protocols, but keep future protocol versions in mind
- support the use of third-party plug-ins for SSL/TLS encryption (like StreamSec Tools 4)

To avoid conflicts with the RTC SDK, so that both the RTC SDK and this new library can be used and/or installed at the same time in Delphi, we will be using a different name-scheme for this new library. You won't be able to use the same Port number for a Server build with the RTC SDK and a Server built with this new library, since the new library will NOT be sharing ANY code with the RTC SDK, but ... it would allow you to port your existing code from RTC SDK to this new library using a single IDE, and ... if needed ... continue using the RTC SDK in some of your Projects, even if it won't be actively supported by us anymore.

With that, I hope it's pretty clear where we are heading.

END OF QUOTE

In other words, the RealThinClient SDK is now in maintenance-only mode and will NOT receive any updates, unless we find some critical bug that needs fixing.

I understand that some of you might be angry at me and/or Mr. Okada for abandoning the RTC SDK in favor of  a much simpler solution, but you need to understand that RTC SDK has become a monster of a product over the last 15 years, while the RTC user-base has continuously been shrinking, making it harder and harder to justify its continued development and support.

With a shrinking user-base and a growing code-base, we've reached a point where it simply does NOT make any more sense to continue investing in the development and support of all the features and platforms currently implemented in RTC SDK, so we have decided to freeze the RTC SDK in a stable state and continue providing technical support, while we focus on building a new light-weight alternative for developing pure web-based solutions, which would be much easier to maintain and support on the long run.

Our plan is to write a new library using the absolute minimum code necessary for building stand-alone HTTP/S Servers for Windows, so we can avoid getting into the same situation again in the future, where there is too much code to maintain and it became too complicated to add support for new protocols.

If anyone does NOT like our decision, I recommend you to cancel your RTC subscription and find an alternative, because insulting posts are NOT going to solve anything.

Hello Stefanos!

We are sitting in the same boat. I also bought it because of cross-platform support and we are also developing POS solutions.
The funny thing is that the homepage text was changed:
Main highlight (first feature) "Cross-Platform: Target Windows, Mac OSX, IOS & Android from a single code-base" was silently removed - but I have a screenshot!  ;)

So Stefanos are you searching already for alternatives as proposed by RTC?
I do at least... But it's not so easy to replace such core communication protocol with another one. You need to update all the clients / not compatible with old RTC version anymore!
Or you have to even create a new product! It's like to switch to another language.

Best regards,
   Werner

Hi Werner,
    this is what happens when we depend our software on a one man business. Same thing happened with PAXCompiler. Both great products that got bought-off. I have noticed the change in RTC site too, but if you press DETAILS the platforms are still there !!!!  ;). Anyway, we have successfully compiled the latest RTC 9.50 with Delphi 10.3.3 Beta for Androidx64 and for macOSx64 with 10.3.2. So all platforms are supported out of the box with the current version of RTC. We have decided to keep using RTC for the time being, (since we are on support until August 2020) but we are also considering other options like:

a) mORMot
b) RemoteSDK
c) Datasnap (we have Delphi Enterprise License)
d) try to support RTC on our own since we have the source

Regards,

Stefanos

Any pointers on getting v9.50 working for macOSx64?  Maybe a list of edits/changes you made to get it to work/compile/install.  I'm sure others would appreciate it as well.

Just now getting around to updating from 10.3.1 to 10.3.2 just so I can start using macOSx64.  Came here to look for an updated version only to find out this bad news! :(

Thanks,
Scott

Hi SevenOut,
     we compiled RTC 9.50 packages with 10.3.2 for macOSx64 and successfully run the stress test client demo on macOS Mojave 10.14. We will make further tests on macOS Catalina 10.15 (supports only 64bit Apps). For Androidx64 we compiled with 10.3.3 Beta (SugarLoaf) and successfully run a test project that we had in Android 9.1. We did not make any modifications to the source code of RTC, just added the extra platforms to the RTC packages. We strongly suggest that your run your own tests against your codebase...

Stefanos

I'm happy to see that this topic is finally going in the right direction.

Thanks!

Scott

Stefanos,

Maybe I did something wrong but the macOS 64bit is not working for RTC 9.50 for me.  I did a clean install of Rad Studio 10.3.2.  Added the RTC Lib path to all the platforms.  I opened the SDKPackages_Main project group.  macOS64 and iOS64 were already listed under the Target Platforms.  I manually added iOS32, macOS32, iOS Simulator, and Android for each of the packages (rtcSDK and rtcSDKD).  I installed the run-time and then the design time packages with no errors.  When I now create a new multi-device test project, and select macOS64 as the target platform, all the RTC components on the palette are disabled.  If I hover over any of them, the Supported Platforms popup window shows all platforms except for macOS64.  Any clues/help as to what I did wrong or need to do differently?

Thanks

Scott

That is a design-time thingy. It doesn't affect your Project at run-time. You can switch to 32-bit MacOS platform when designing and only change to 64-bit when you need to compile the Project for 64-bit, or ... you can open the "rtcTypes.pas" unit and update the list of supported platforms defined with "pid*" variables. This is how the list looks without modifications ...

  // @exclude
  pidWin32        = $0001;
  // @exclude
  pidWin64        = $0002;
  // @exclude
  pidOSX32        = $0004;
  // @exclude
  pidiOSSimulator = $0008;
  // @exclude
  pidAndroid      = $0010;
  // @exclude
  pidLinux32      = $0020;
  // @exclude
  pidiOSDevice32  = $0040;
  // @exclude
  pidLinux64      = $0080;
  // @exclude
  pidWinNX32      = $0100;
  // @exclude
  pidWinIoT32     = $0200; // Embedded IoT (Internet of Things) Windows w/ Intel Galileo
  // @exclude
  pidiOSDevice64  = $0400;

  // @exclude
  pidLinux = pidLinux32 or pidLinux64;
  // @exclude
  pidWindows = pidWin32 or pidWin64 or pidWinIoT32 or pidWinNX32;
  // @exclude
  pidMacOSX  = pidOSX32;
  // @exclude
  pidDesktop = pidWindows or pidMacOSX or pidLinux;
  // @exclude
  pidMobile  = pidiOSSimulator or pidiOSDevice32 or pidiOSDevice64 or pidAndroid;
  // @exclude
  pidAll     = pidDesktop or pidMobile;

I hope that helps.

Thanks.

I was just looking at that file and comparing it to the System.Classes unit.  It contains almost exactly the same thing. 

Scott

These are the only variables that RTC components use to tell the Delphi IDE which platforms are supported:

  pidLinux = pidLinux32 or pidLinux64;
  pidWindows = pidWin32 or pidWin64 or pidWinIoT32 or pidWinNX32;
  pidMacOSX  = pidOSX32;
  pidDesktop = pidWindows or pidMacOSX or pidLinux;
  pidMobile  = pidiOSSimulator or pidiOSDevice32 or pidiOSDevice64 or pidAndroid;
  pidAll     = pidDesktop or pidMobile;

If the pidAll variable includes all the supported platforms, then RTC components should be enabled in the IDE when you select one of these platforms. That's all there is to it, really.

Since pidAll is just an integer (word?), where each bit represents a flag for one of the supported platforms, a quick-and-dirty solution (untested) might be to set:

  pidAll     = $FFFF;

You can give that a try, if you can't find the declaration of constants for newly added platforms in Delphi sources.