What would you like to see from RealThinClient next?

[D.Tkalcec (RTC)]

Where would you like to see the RealThinClient move forward next? You can select 2 options, please choose the ones which are most important to you.

Thank you.

Best Regards,
Danijel Tkalcec

[Michael]

Hallo Danijel!

Everything is required - why not already here:-).

I have one on Java - this is something I smell. Beyond between JBOSS and JAX-X RPC there is room left. Just an idea but this requires to be conformant to what is well known in the Java area. Usually they are all satisfied with what comes on board, just my experience All the other ideas are good too.

[Kevin Powick]

Lots of great choices Danijel.  Can't you just do them all? 

There seems to be a little overlap with some choices that are separated into client/server for the same platform.  Wouldn't it be odd to have a SDK that only supported one side of the client/server relationship?

Cheers,

[D.Tkalcec (RTC)]

I would like to do all of these things, but I can't do them all at once so I need to prioritize.

As for the Client/Server separation in cross-platform options, I have allowed everyone to place 2 votes so you can vote for the Client and the Server side for one platform if you need that platform fully supported. It is also very much possible that someone would only be interested in Linux or MacOSX clients talking to their Windows Server, while someone else might be interested in moving their Server-side Web Application to Linux.

Best Regards,
Danijel Tkalcec

[Michael]

I think Visual Integration into Lazarus is not required ... I think the vote already shows an interesting picture. Linux on the server side is very realistic. Anything else I think ... the moment we have Delphi and FPC and Apple und 32 and 64bit I fear we will endup in just maintenance.

Mike

[Kevin Powick]

I think the vote already shows an interesting picture.

The problem, as with all polls and surveys, is that only a fraction of the user base ever votes or comments.

--
Kevin Powick

[D.Tkalcec (RTC)]

It looks like this voting has been pretty much decided.

With 50% of voters placing their vote for Database access components (RTC DBA), there is no question about what I should focus on completing next.

The 2nd and 3rd positions are not so clearly separated, but adding JSON support to the RTC SDK is pretty easy, so I will be focusing on JSON as my 2nd target.

RTC VCL is quite a beast, so I can't make any short-term plans for its release, but I can prioritize it to get it finished faster.

As for the rest, the latest RTC SDK version should already be compatible with FPC/Lazarus and the low-level Linux socket implementation should work (only RTC Timers need to be made cross-platform), so anyone interested in FPC/Lazarus support for Linux can give it a try and post about any problems they might encounter.

PS. Anyone wants to comment on the results?

Best Regards,
Danijel Tkalcec

[kavetu]

Oh, that would be great if I could compile my RTC-based server on Linux
using free pascal (avoiding usage of rtc timers until they are ready for Linux),
that should be really great Danijel.

My RTC-based web application server went live about two months ago, running
for the last two months without a single iota of issues, very stable as the rock
of gilbraltar. I am working in a Registrar of Deeds Office and in about a period
of 8 months we managed to scan over 215,000 title deeds (size range between
250 KB to 1.5 MB). The title deeds are
scanned as PDF images and stored in an Oracle Blob field, and retrieving those
images via our RTC-based application server using a win32 client
(designed with Delphi 2010) is almost instantaneous on the LAN. Here is the code
that retrieves an image (PDF file) from an Oracle Blob (on the
RTC Application Server side):

procedure TdmoDatabase.SelectDocumentImage(documents_id: integer; var Msg: string; rtcDS:TRtcDataSet);
var
  mem: TStream;
begin
  {Open qryGetDocumentImage dataset}
  try
    //qryGetDocumentImage is a TOraQuery object
    qryGetDocumentImage.Close;
    qryGetDocumentImage.ParamByName('DOCUMENTS_ID').AsInteger := documents_id;
    qryGetDocumentImage.Open;
    Msg := '0';
  except
    on E:Exception do
      Msg := 'Exception: '+E.Message;
  end;

  if Msg = '0' then
  begin
    {Assign FIELDS to rtcDS}
    rtcDS.Clear;

    rtcDS.SetField('DOCUMENTS_BLOB_ID',ft_Integer,0,True);
    rtcDS.SetField('DOCUMENTS_ID',ft_Integer,0,True);
    rtcDS.SetField('DOC_IMAGE',ft_Blob,0,True);
    rtcDS.SetField('MIGRATION',ft_Integer,0,True);
    rtcDS.SetField('DOC_REF_NO',ft_String,50,True);
    rtcDS.SetField('BARCODE',ft_String,50,True);

    {Now copy the IMAGE from qryGetDocumentImage dataset to rtcDS}
    qryGetDocumentImage.First;
    rtcDS.Append;

    rtcDS.FieldByName('DOCUMENTS_BLOB_ID').asInteger := qryGetDocumentImage.FieldByName('DOCUMENTS_BLOB_ID').AsInteger;
    rtcDS.FieldByName('DOCUMENTS_ID').asInteger := qryGetDocumentImage.FieldByName('DOCUMENTS_ID').AsInteger;
    rtcDS.FieldByName('MIGRATION').asInteger := qryGetDocumentImage.FieldByName('MIGRATION').AsInteger;
    rtcDS.FieldByName('DOC_REF_NO').asString := qryGetDocumentImage.FieldByName('DOC_REF_NO').AsString;
    rtcDS.FieldByName('BARCODE').asString := qryGetDocumentImage.FieldByName('BARCODE').AsString;

    mem := qryGetDocumentImage.CreateBlobStream(qryGetDocumentImage.FieldByName('DOC_IMAGE'),bmRead);
    try
      try
        rtcDS.NewByteStream('DOC_IMAGE').CopyFrom(mem,0);
        Msg := '0';
      except
        on E:Exception do
          Msg := 'Exception: '+E.Message;
      end;
    finally
      mem.Free;
    end;
  end;
end;

And here is the code on the client side that receives the blob image from
the RTC Server:

procedure TfrmDocuments.RtcImageReturn(Sender: TRtcConnection; Data,
  Result: TRtcValue);
var
  msg: string;
  stream: TMemoryStream;
begin
  msg := dmoGlobal.ProcessRtcResultExceptions(Result);
  if msg = 'ds' then
  begin
    if not Result.asDataSet.Empty then
    begin
      Result.asDataSet.First;
      stream := TMemoryStream.Create;
      try
        Delete_File('dwas.pdf');
        stream.LoadFromStream(Result.asDataSet.FieldByName('DOC_IMAGE').asByteStream);
        if stream.Size > 0 then
        begin
          stream.SaveToFile('dwas.pdf');
          if FileExists('dwas.pdf') then
            AcroPDF.LoadFile('dwas.pdf');
          PageControl.ActivePage := TabImage;
        end
        else
          dmoGlobal.MessageOut('No image found on the server.');
      finally
        stream.Free;
      end;
    end;
  end
  else
    dmoGlobal.MessageOut(msg);
end;

Everything works nice, and both the client and Rtc-based application server
are extremely stable.

Manfredt Kavetu

[D.Tkalcec (RTC)]

Thank you for sharing

Best Regards,
Danijel Tkalcec

[ArcticRD]

Hi Danijel,

We use Nexus Portal and aren't using RealThinClient components directly. We voted for option "something else".

Here our wish list, from Nexus Portal perspective:
1. Keep focus on reliablity and quality also in the future.
2. Direct / P2P transfer would be a nice feature. In cases where hosts / controllers are inside the same network, it would make screen updates faster and save bandwidth if data goes directly. If P2P option is enabled, first try direct transfer. If that doesn't succeed for some reason like firewall, then route everything through gateway.
3. UDP transfer option. If you want smallest delays in screen updates, data should be sent as UDP traffic. Having UDP support would enable real time audio transfer possibilities etc.

[D.Tkalcec (RTC)]

Hi ArcticRD,

1. Reliability and Quality have always been my top priority for RealThinClient components and that will never change.

2. RTC SDK has Client and Server components and thus allows you to make direct connections between 2 PCs (one being a Client, the other being a Server).

3. You can already use UDP with RTC SDK through the TRtcMessageClient and TRtcMessageServer components by using custom transports (for example, NexusDB transports).

Best Regards,
Danijel Tkalcec