Linked Objects (v4.11)

[Kevin Powick]

Is there any chance that this beta code can affect the stability of RTC?  IOW, is it completely safe to use version 4.11 if one does not use any Linked Object functionality?

The notification sent out on this mentioned : "Linked Classes" (paired visual and non-visual components) where a Client-side instance (object, non-visual or visual component) will automatically be created for each Server-side instance you create in code.

Maybe I'm reading this wrong, but it sounds like a client side visual object can be created by code written on the server side.   It seems that it should be the other way around, no?  Please clarify with an example if you can.

Would communication between client/server objects be completely transparent to the developer?  If so, and they developer doesn't have to (or cannot) control messaging between sides, is there any concern about the amount of network traffic that might be generated?

Overall, Linked Objects sound interesting for certain system designs and I'm looking forward to learning more about them.

[D.Tkalcec (RTC)]

Hi Kevin,

1) Even though the new "RTC Linked Objects" functionality is pretty much isolated from the rest of the RTC SDK by using completely new classes and adding a requirement to extended classes explicitly enable "Linked Objects" features before any new code is used (for example, you need to set "AutoLinkedObjects" property to TRUE for extensions in the TRtcClientModule and TRtcServerModule components to have an effect), I still wouldn't recommend using RTC SDK v.411 in production, simply because it is still in BETA (not fully tested).

2) Technically speaking, the "RTC Linked Objects" framework does NOT explicitly define which side is responsible for object creation in code and which side should re-create instances automatically, because both sides use the same "communication interface" and can send the same kind of info to the other side. But ...

2.A) For the communication to actually work, the framework requires an "Object Manager" to be activated before you create a new "RTC Linked Object" instance. And if that object creation process (in code) is done on the Server-side and remains limited to specific events executed on RTC SDK components (for example, the "OnExecute" event used by the "TRtcServerModule" component to execute remote function calls), the RTC SDK can easily handle all the preparations and transparently handle all the communication between "Linked Objects" created there.

For example, if you wanted to use the Delphi IDE to design Server-side Forms, so they could be sent to the Client as a result of a remote function call, without the Client having to know anything about that Form being received (for example - a "Progress Dialog" created by the Server and updated by the Server). In that case, the Server could create the Form needed for the job, Client would receive and display the Form automatically after receiving the function result from the Server. The User would interact with the Form as if it was created by the Client "in code", but all the user events would be sent to the Server and executed directly on the Server - where the Form was created and where that information would have a meaning. This is not very different from how Web Applications are working.

2.B) Before a Server does something for a Client, I think it should check if the Client is ALLOWED to do even ask for that. In other words, a Server should be able to perform a "user check". For this purpose, the Client could either send all the required information as parameters to the remote call which would be used for creating "RTC Linked Objects" (also provide parameters required for creating objects), or ... the Client might already have used other ways (for example, a login remote call) to prepare the information which the Server could have stored inside user Session - which would also be available in the remote call which requests "RTC Linked Objects" to be created.

An option for Clients to have objects automatically created for them on the Server could become a security and stability risk for the Server. Any Client knowing about classes available on the Server could misuse that "feature" to bring the Server to a crash (for example, sending requests which would result in objects being created automatically until the Server runs out of memory), or even worse (if user access rights aren't being checked by the components) gain access to data which should be restricted. That's why I'm not comfortable with the idea to include a feature inside a Server which would allow Clients to "trick" the Server into creating objects automatically, or where special out-of-place precautions would need to be made by the developer to ensure that Clients won't start doing things on the Server which they aren't supposed to do.

3) There won't be any "hidden requests" to handle the communication when using "RTC Linked Objects" with the RTC SDK. Classes implementing "RTC Linked Objects" call methods on the associated "Object Manager" if they want to inform their "counterpart" of something they find "important". The "Object Manager" puts that information into its buffer and notifies the communication components about new data. The communication component, once ready for sending, will contact the "Object Manager" to get the package and send it to the other side. In other words, there amount of data being sent and received is defined by the "RTC Linked Object" implementations used and - by adding events on Object Manager methods - it would be possible to monitor all communication.

Best Regards,
Danijel Tkalcec