How about "Rapid Rich Internet Application Development"?
Danijel Tkalcec
I have had this "crazy" idea since 2004 that HTML with JavaScript running
inside a Browser (AJAX) just isn't good enough to become a replacement for
todays Rich Client/Server and N-Tier Windows Applications. Even with all the
third-party components and tools available today for writing AJAX Web
Applications, the results in most areas are less than acceptable for the
end-user. HTML, even when combined with the best JavaScript, just doesn't
give us the same UI quality we are used to having with Windows Clients.
I think we have an excellent development tool in Delphi, but when it comes
to writing mid-tier applications, IMHO, all the solutions currently
available are either too complex for use in large-scale projects, or they
are just too limiting. Wouldn't it make more sense to use the Delphi IDE for
writing mid-tier applications in the exact same way you can write desktop
applications? Why should application developers have to separate their code
into a client and a server "manually" when it all boils down into a single
codebase? Why would one have to fetch hundreds of records from a database
and send it over a wire to allow the user to see them in a Grid? Or
artificially "split" large datassets into pages to reduce the traffic? And
why should an application developer have to manually write remote
functions/objects on the server and then write code on the Client to call
these functions?
Wouldn't it be more feasible to presume that clients are there as a
presentation layer for the server, taking care of user interaction, while
all the business logic belongs into the server? And then allow the developer
to design both parts of the puzzle in a single project, building a single
application which would automatically be split into a Server holding all the
information and business logic and a Client being the presntation layer and
taking responsibility for user interaction?
Is this impossible to achieve?
Not at all.
But ... to get this kind of functionality working transparently for the
developer, we need a framework with a large enough set of components which
can take care of client/server separation and all the communucation for us.
And this is what I have working on in the past months, with good results: I
now have the basic framework in place, which includes the Application, Form,
DataModule, Edit, Label and Button components with full Delphi/C++Builder
IDE integration. The framework is completely transport agnostic, which means
that it can be combined with any communications component set (like the RTC
SDK, for example). The basic framework is relatively easy to use by
component developers, but making a visual component usable in the context
explained above requires detailed knowledge of the component being
"ported" - and "a bit" of coding.
To demonstrate what would have to be done to make simple visual components
usable with this framework, I have uploaded two units (Client- and
Server-side) implementing the Button, Label and Edit components. If you want
to take a look, please download and unpack this ZIP file:
http://www.realthinclient.com/temp/rtcfSample.zip
Since I now have the framework in place with major problems of client/server
components separation solved (server with low resource requirements and
optimized code for minimum CPU usage), I was hoping to find developers
(component vendors?) seriously interested in spending their time (with me)
in an effort to get this idea materialized. If you would like to participate
in this huge undertaking, please let me know where you see yourself and how
you think our cooperation should look like. To contact me, please send an
E-Mail to the "General Questions" address listed here:
http://www.realthinclient.com/contact.htm
Thank you for your time :-)
Best Regards,
Danijel Tkalcec, Team RTC
http://www.realthinclient.com
Tony Caduto
Danijel Tkalcec
> So is this a citrix like hybrid type of thing or a Intraweb clone?
Not even close.
Citrix is extremely resource and bandwidth hungry (read: it is slow and can
serve only a small number of clients). IntraWeb is limited to
HTML+JavaScript. What I am talking about will not require more resources
than an average N-Tier Server (RTC WebServer can host a thousand clients -
can Citrix do that?), but client interaction will be X times faster than a
Terminal Client/Server solution, while being a lot richer and
user-interactive than a Browser-based HTML+JavaScript application can be.
It you are looking for a comparison, it will require a bit more memory than
the same application using remote functions, but will otherwise give you the
same or better performance than you can achieve by splitting the code in
client and server manually.
Best Regards,
Danijel Tkalcec
Farshad
components!?
Tony Caduto
> "Tony Caduto" schrieb:
>> So is this a citrix like hybrid type of thing or a Intraweb clone?
>
> Not even close.
>
so it's doesn't use a browser at all on the client side?
Danijel Tkalcec
> If I understand correctly you want to implement your own browser using VCL
> components!?
Very close.
Using the client-side components, a "Browser" for VCL applications would be
compiled (I would call it a Player, since it is more similar in
functionality to a FLASH or a SHOCHWAVE player) and used to run applications
hosted by a Server written with Delphi and using their Server-side
counterparts. The "Browser" could also be extended by anyone with new
components and more functionality (components for 3D presentations,
animations, client-side calculations - everything is possible). Since the
whole framework is component-based, all third-party component vendors
currently offering components for Delphi could make their visual components
work with the Framework and offer them as add-ons.
Best Regards,
Danijel Tkalcec
Yannis
"Farshad" <far...@ATfmsoftDOT.net> wrote:
>If I understand correctly you want to implement your own browser
> using VCL components!?
No not exactly.
Browsers are nothing more than super charged document viewers.
Do not forget that HTML is nothing more than a document format
suitable for multi client view. Now the current trend is to make
this viewer an application base which is like trying to change
acrobat reader in to an overall application consumer/player.
What the current offer is, as far as I understand it, is a dynamic
application that can change it's appearance based on a specific
protocol and commands/objects. It is a different beast altogether
and probably closer to what the goal of web applications is from
the start.
A nice idea I must admit.
regards
Yannis.
Danijel Tkalcec
I couldn't have said it better.
The Server-side components will not be sent to the Client ("Browser/Player")
as documents, but more like commands which need to be executed by the Client
in order to give you the apearance you wanted. This means that changing a
property in your code will change that same property on the Client. Creating
or destroying components in the Server will do the same on the Client. When
a Client triggers an event, that event will be executed by the Server and
all changes done in server-side code will be sent back to the client to
update the display.
> A nice idea I must admit.
Thank you :o)
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
If you are reffering to a WebBrowser like IE or Firefox, then the answer is
a clear NO. It does NOT use a Browser at all. It uses a specially compiled
Client which acts like a "Browser". The "Browser" would be compiled by using
the client-side framework and client-side components in Delphi (or in
FPC/Lazarus if someone should write client-side components for Lazarus).
Best Regards,
Danijel Tkalcec
Michael Justin
> Wouldn't it be more feasible to presume that clients are there as a
> presentation layer for the server, taking care of user interaction,
> while all the business logic belongs into the server? And then allow the
> developer to design both parts of the puzzle in a single project,
> building a single application which would automatically be split into a
> Server holding all the information and business logic and a Client being
> the presntation layer and taking responsibility for user interaction?
There is already a Java product which is very close to what you
describe: UltraLightClient (ULC), http://www.canoo.com/ulc/
It uses the standard Java GUI classes (Swing) on the client side.
However, they are extended in a way that allows to implement their
behaviour on the server side: "Each Swing component on the client is
complemented with a corresponding server-side component. In this way,
you can use the ULC-enabled Swing components as if they were running on
the server."
Pro: very easy to write rich clients
Con: GUI implementation is limited to the provided ULC proxy classes
(ULCTable instead of JTable tec.), a typical case of vendor lock-in
--
Michael Justin
SCJP, SCJA
betasoft - Software for Delphi™ and for the Java™ platform
http://www.mikejustin.com - http://www.betabeans.de
Danijel Tkalcec
> Danijel Tkalcec schrieb:
>
>> Wouldn't it be more feasible to presume that clients are there as a
>> presentation layer for the server, taking care of user interaction, while
>> all the business logic belongs into the server? And then allow the
>> developer to design both parts of the puzzle in a single project,
>> building a single application which would automatically be split into a
>> Server holding all the information and business logic and a Client being
>> the presntation layer and taking responsibility for user interaction?
>
> There is already a Java product which is very close to what you describe:
> UltraLightClient (ULC), http://www.canoo.com/ulc/
>
> It uses the standard Java GUI classes (Swing) on the client side. However,
> they are extended in a way that allows to implement their behaviour on the
> server side: "Each Swing component on the client is complemented with a
> corresponding server-side component. In this way, you can use the
> ULC-enabled Swing components as if they were running on the server."
>
> Pro: very easy to write rich clients
> Con: GUI implementation is limited to the provided ULC proxy classes
> (ULCTable instead of JTable tec.), a typical case of vendor lock-in
I didn't know about that project, but you are right. This comes very close
to my idea, except that I'm targeting Delphi as development platform (not
Java) for the Server and a native Windows Client (should run on Linux under
on WINE) instead of a Java client. The vendor lock-in problem can be solved
if the idea gets through and third-party component vendors decide to make
"proxy classes" for their components.
Also, the framework should be easy enough for use by most developers, so ...
if there is a component you absolutely do not want to live without which
does not have proxy classes for the new framework, you could go and write
client- and server-side proxy classes yourself, and maybe even start your
own component development business as your collection grows. I think this
could open a completely new Delphi components market :o)
Best Regards,
Danijel Tkalcec
Kevin Powick
> Using the client-side components, a "Browser" for VCL applications
> would be compiled (I would call it a Player, since it is more similar
> in functionality to a FLASH or a SHOCHWAVE player) and used to run
> applications hosted by a Server written with Delphi and using their
> Server-side counterparts.
I've wanted something like this for a while, without having to resort
to web browser apps, or something like Flex/Flash.
I've seen this approach with some products that try to GUIize
mainframe, dumb terminal apps. You use a terminal emulator/player that
interpreters codes sent from the mainframe application to create GUI
elements such as windows, buttons, edit boxes, etc. Unfotunately, in
these cases, it's pretty weak due to the limited number of GUI elements
these tools make available and the amount of hand coding required on
the server side.
What I like about the concept you're proposing is that it's all Delphi.
The big trick will be getting component vendors on board. You'll
probably have to create a decent set of the default Delphi components
to prove that it's viable before you convince 3rd party developers to
put the effort into it.
It should be interesting. Let us know when you have a downloadable
"player" that we can demo a simple server app running at your end.
--
Kevin Powick
Robert Baker
> I have had this "crazy" idea since 2004 that HTML with JavaScript running
> inside a Browser (AJAX) just isn't good enough to become a replacement for
> of client/server separation and all the communucation for us.
I recall seeing something like this years ago. It was based on ASTA.
In any case I lost the link, does anyone else remember this product?
Robert Baker
Danijel Tkalcec
>
> What I like about the concept you're proposing is that it's all Delphi.
> The big trick will be getting component vendors on board. You'll
> probably have to create a decent set of the default Delphi components
> to prove that it's viable before you convince 3rd party developers to
> put the effort into it.
Most likely.
> It should be interesting. Let us know when you have a downloadable
> "player" that we can demo a simple server app running at your end.
It could take a while before I have a demo worth looking at,
but when I do have somethingready, I will post it here and
hopefully get swamped under loads of feedback =:o)
Best Regards,
Danijel Tkalcec
Srinivasan Iyer
Have you given any consideration to deployment of clients?. It would be nice if
client can sense if server has changed and update themselves. If the framework
can generate multiple types of client codes depending on the end-user functions
and rights it would be really great.
Srini.
Rita
"Danijel Tkalcec" <r...@deltasoft.hr> wrote in message
news:4829...@newsgroups.borland.com...
> Hello, Developers!
Danijel interesting very interesting. Have you got the smarts to write it
yourself ?
Are you looking for funding or just developers to get it working ?
I dont get why you want component makers to take it up ?
Rita
Farshad
Actually, that's something that I was thinking about for a while. I'm
planning to create a framework for my apps which enables me writing dynamic
thin clients. The thin client will create application Forms dynamically
using form data stored in a database. I wanted to implement something close
to your project but I found out that implementation won't be that easy.
Communication protocols, transport layers, dynamic object creation, event
handling and many other considerations.
"Danijel Tkalcec"
Danijel Tkalcec
>
> Actually, that's something that I was thinking about for a while. I'm
> planning to create a framework for my apps which enables me writing
> dynamic thin clients. The thin client will create application Forms
> dynamically using form data stored in a database. I wanted to implement
> something close to your project but I found out that implementation won't
> be that easy. Communication protocols, transport layers, dynamic object
> creation, event handling and many other considerations.
Well ... for these things, I already have a working solution. The framework
takes care of dynamic component creation and destruction, manipulation,
event mapping and execution. Simply everything needed to implement any kind
of visual and non-visual component. And the first Form, DataModule, Button,
Label and Edit components are now fully functional, with all their
properties and events. What remains to be done are more components using the
framework.
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
Client could update itself from the Server, but this would only be needed if
new components are added to the framework. Client will not need to be
updated as new functionality (forms and/or datamodules) is being added to
the Server. As far as access rights go, the first Form sent to the Client
would be the Main form of the application and would usually display a login
mask. Everything else is then handled by Server-side code.
Best Regards,
Danijel Tkalcec
Andreas Hausladen
> Client could update itself from the Server, but this would only be
> needed if new components are added to the framework. Client will not
> need to be updated as new functionality (forms and/or datamodules) is
> being added to the Server.
This sounds exactly like the thing that my boss told me to think about
in the next weeks.
--
Regards,
Andreas Hausladen
Danijel Tkalcec
>
> "Danijel Tkalcec" wrote:
>> Hello, Developers!
>
> Danijel interesting very interesting. Have you got the smarts to write it
> yourself ?
I have the framework already implemented and tested, including the first few
visual components and a test project I was using for debugging. So ... yes,
I think I can do it by myself. The only question is: how long will this take
me to write enough proxy classes to make the framework interesting?
> Are you looking for funding or just developers to get it working ?
> I dont get why you want component makers to take it up ?
There are a lot of components available to Delphi developers - beyond the
standard Delphi palette. Even though I will most likely have to implement
proxy classes for the standard Delphi components, there are too many
third-party components which developers have gotten used to, where the
third-party component authors would need to make necessary modifications and
write proxy classes for the framework. And one of the reasons for my post
here was to see if there is interest for this kind of components in the
Delphi community (potential customers) and also find out if there are
third-party component vendors interested in starting to prepare their
components for this new framework while I am working on proxy classes for
the standard Delphi components.
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
> "Rita" schrieb:
>>
>> "Danijel Tkalcec" wrote:
>>> Hello, Developers!
>>
>> Danijel interesting very interesting. Have you got the smarts to write it
>> yourself ?
>
> I have the framework already implemented and tested, including the first
> few visual components and a test project I was using for debugging. So ...
> yes, I think I can do it by myself. The only question is: how long will
> this take me to write enough proxy classes to make the framework
> interesting?
>
>> Are you looking for funding or just developers to get it working ?
>> I dont get why you want component makers to take it up ?
>
> There are a lot of components available to Delphi developers - beyond the
> standard Delphi palette. Even though I will most likely have to implement
> proxy classes for the standard Delphi components,
Well, actually ... since the components will be commercial (not sure about
the price, though), some developers might be interested in taking up the
task of implementing a proxy class for one or two standard Delphi components
(there is a lot to choose from) in exchange of a commercial license with a
lifetime subscription. I could always use a helping hand-or-two to speed
things up :o)
Best Regards,
Danijel Tkalcec
Tony Caduto
> If you are reffering to a WebBrowser like IE or Firefox, then the answer
> is a clear NO. It does NOT use a Browser at all. It uses a specially
> compiled Client which acts like a "Browser". The "Browser" would be
> compiled by using the client-side framework and client-side components
> in Delphi (or in FPC/Lazarus if someone should write client-side
> components for Lazarus).
I could see this as working if you make it so it can run as a browser
plugin or something where the user would not have to install anything.
The popularity of web applications has something to do with the fact you
only need a browser and nothing else.
Danijel Tkalcec
I am sure the Client could be made available as a browser plugin, too. I
know that Anthoni (RTC Team member) has already written plugins for IE and
Firefox with Delphi and used the RTC Client components inside the plugin. An
alternative would be simply to make the client EXE as a download link on the
Server (which would be a HTTP server when built with the RTC SDK).
Best Regards,
Danijel Tkalcec
Tony Caduto
>
> I am sure the Client could be made available as a browser plugin, too. I
> know that Anthoni (RTC Team member) has already written plugins for IE
> and Firefox with Delphi and used the RTC Client components inside the
> plugin. An alternative would be simply to make the client EXE as a
> download link on the Server (which would be a HTTP server when built
> with the RTC SDK).
That would be very cool then.
So when you say it's like a player, the application would be running on
the server and basically the client is going to be getting it's display,
so in that regards it's kind of like citrix, but without the overhead?
Danijel Tkalcec
With Citrix, you have multiple application instances running on the server
which are sending graphical commands from the Server to the Client, while
the Client is sending all mouse movements, mouse clicks and keyboard events
to the Server. This is a lot of unnecessary communication. With what I am
proposing, the situation is completely different because:
1) There will be only one server application instance. To "similate"
multiple applications running on the server, only form/datamodule proxy
classes will be created by the Server. This results in A LOT less memory
consumption than the Terminal Client/Server (Citrix) approach.
2) The "Player" will be a very small executable with no need to install
anything. Simply run the exe and you are on the Server. Server address and
port can be compiled into the player, so the user running the Client would
not even know that he is actually running an application hosted by the
Server.
3) While Citrix is sending simple graphical commands from the Server to the
Client and sending all mouse and keyboard events from the Client to the
Server, there is A LOT of unnecessary and highly unoptimized communication
going on between each Client and the Server. This will NOT be the case with
what I am proposing, since this new framework will not be sending graphical
commands or all mouse/keyboard events back and forth. Instead, it will be
creating real Windows components (Edits, Grids, Pagecontrols on Forms and
sub-Forms) and data will be sent from client to Server only when the
component says so. If the OnMouseMove event is not mapped on a component,
then that event will not trigger any kind of communication. If an edit field
is modified 20 times before someone clicks the "OK" button and there is no
"OnChange" event for the edit box implemented, then only the last state of
the Edit field will be send on the button click and not every single
keystroke.
So ... even though you might say that the functionality is somewhat similar
to Citrix, it uses an entirely different approach, which gives you a lot
more power (much better performance with fluid user interaction) while
asking for a lot less resources (CPU, Memory, bandwidth requirements are A
LOT lower).
Best Regards,
Danijel Tkalcec
Rita
"Andreas Hausladen" <AndreasDO...@gObviousToBeRemovedmx.de> wrote in
message news:4829...@newsgroups.borland.com...
>
> This sounds exactly like the thing that my boss told me to think about
> in the next weeks.
>
This gets more and more interesting, I really want whatever it is now ;-)
If I was your boss you would be writing a Kylix clone.
I hope the new owners spot this thread it would recover their stake +
the database arm would go through the roof.
Happy days are here again.
Rita
Unknown
> the price, though), some developers might be interested in taking up the
> task of implementing a proxy class for one or two standard Delphi
components
> (there is a lot to choose from) in exchange of a commercial license with a
> lifetime subscription. I could always use a helping hand-or-two to speed
> things up :o)
You've already written some proxies for components. Could you guess a time
frame for an average developer to write the proxy class for some databound
(e.g. TEdit) field? Have you already been working on a proxy class for a
TDBGrid (scrollbar location, etc)? How much time would that cost? (I'm kind
of lazy and did not check your example code yet, will do that)
BTW: take a look at this thread -although the approach is different- some of
the drawbacks mentioned could be valid:
http://groups.google.com/group/borland.public.delphi.non-technical/msg/320494c3ef3f1220
Gert
P.S. One request: think about the right license carefully ;-)
Farshad
"Danijel Tkalcec"
> With Citrix, you have multiple application instances running on the server
> which are sending graphical commands from the Server to the Client, while
> the Client is sending all mouse movements, mouse clicks and keyboard
> events to the Server. This is a lot of unnecessary communication. With
this is close to the way frameworks like IntraWeb or Morfik handle web
applications. The difference is that your front-end will be made of VCL
controls which makes the UI much more responsive and good looking.
Danijel Tkalcec
>> Well, actually ... since the components will be commercial (not sure
>> about
>> the price, though), some developers might be interested in taking up the
>> task of implementing a proxy class for one or two standard Delphi
> components
>> (there is a lot to choose from) in exchange of a commercial license with
>> a
>> lifetime subscription. I could always use a helping hand-or-two to speed
>> things up :o)
>
> You've already written some proxies for components. Could you guess a time
> frame for an average developer to write the proxy class for some databound
> (e.g. TEdit) field?
It took me from one to two days to get each of the three compononents (Edit,
Label, Button) to get implemented and tested, but this includes my efforts
to wrap a lot of the standard TControl and TWinControl code into separate
classes, so ... I'd say someone entirely new would need about a day to write
a proxy for a component like TEdit.
> Have you already been working on a proxy class for a
> TDBGrid (scrollbar location, etc)? How much time would that cost? (I'm
> kind
> of lazy and did not check your example code yet, will do that)
Haven't started on the more complex stuff yet, so I can't say.
> BTW: take a look at this thread -although the approach is different- some
> of
> the drawbacks mentioned could be valid:
> http://groups.google.com/group/borland.public.delphi.non-technical/msg/320494c3ef3f1220
Can you please spell out the possible drawback in this thread? I do not
think it makes sense to combine this thread with another huge old thread
just to list a few things out.
> Gert
>
> P.S. One request: think about the right license carefully ;-)
Now ... why would you say that? ;-)
Best Regards,
Danijel Tkalcec
Paul Hectors
Sounds interesting and I have had the same thoughts about the limitation of
HTML and Javascript.
Could you please tell me if you have considered using Adobe Flex as the RIA.
It is cross platform , has a RAD ide and has the option to compile as a
desktop application. The Adobe Flash player I imagine is known in the
industry and accepted. If you create your own player then I imagine it would
need to get acceptance in the industry before IT departments allow it to be
installed on clients.
From what I can gather one of the main reasons why IT departments want
browser based software is to avoid installing anything on the client.
I have not looked at the details but if the AMF3 specification was
implemented in Delphi you could have binary transfer between the client and
the Delphi backend. This avoids have to write the GUI proxy classes and the
Adobe Flex GUI controls look like they would do the job. For example the
Adobe Datagrid has a lot more feature than TDBGrid.
Best regards,
Paul
"Danijel Tkalcec" <r...@deltasoft.hr> wrote in message
news:4829...@newsgroups.borland.com...
> Hello, Developers!
>
> I have had this "crazy" idea since 2004 that HTML with JavaScript running
> inside a Browser (AJAX) just isn't good enough to become a replacement for
> todays Rich Client/Server and N-Tier Windows Applications. Even with all
> the third-party components and tools available today for writing AJAX Web
> Applications, the results in most areas are less than acceptable for the
> end-user. HTML, even when combined with the best JavaScript, just doesn't
> give us the same UI quality we are used to having with Windows Clients.
>
> I think we have an excellent development tool in Delphi, but when it comes
> to writing mid-tier applications, IMHO, all the solutions currently
> available are either too complex for use in large-scale projects, or they
> are just too limiting. Wouldn't it make more sense to use the Delphi IDE
> for writing mid-tier applications in the exact same way you can write
> desktop applications? Why should application developers have to separate
> their code into a client and a server "manually" when it all boils down
> into a single codebase? Why would one have to fetch hundreds of records
> from a database and send it over a wire to allow the user to see them in a
> Grid? Or artificially "split" large datassets into pages to reduce the
> traffic? And why should an application developer have to manually write
> remote functions/objects on the server and then write code on the Client
> to call these functions?
>
> Wouldn't it be more feasible to presume that clients are there as a
> presentation layer for the server, taking care of user interaction, while
> all the business logic belongs into the server? And then allow the
> developer to design both parts of the puzzle in a single project, building
> a single application which would automatically be split into a Server
> holding all the information and business logic and a Client being the
> presntation layer and taking responsibility for user interaction?
>
> Is this impossible to achieve?
>
> Not at all.
>
> But ... to get this kind of functionality working transparently for the
> developer, we need a framework with a large enough set of components which
> can take care of client/server separation and all the communucation for
> us.
>
> And this is what I have working on in the past months, with good results:
> I now have the basic framework in place, which includes the Application,
> Form, DataModule, Edit, Label and Button components with full
> Delphi/C++Builder IDE integration. The framework is completely transport
> agnostic, which means that it can be combined with any communications
> component set (like the RTC SDK, for example). The basic framework is
> relatively easy to use by component developers, but making a visual
> component usable in the context explained above requires detailed
> knowledge of the component being "ported" - and "a bit" of coding.
>
> To demonstrate what would have to be done to make simple visual components
> usable with this framework, I have uploaded two units (Client- and
> Server-side) implementing the Button, Label and Edit components. If you
> want to take a look, please download and unpack this ZIP file:
> http://www.realthinclient.com/temp/rtcfSample.zip
>
> Since I now have the framework in place with major problems of
> client/server components separation solved (server with low resource
> requirements and optimized code for minimum CPU usage), I was hoping to
> find developers (component vendors?) seriously interested in spending
> their time (with me) in an effort to get this idea materialized. If you
> would like to participate in this huge undertaking, please let me know
> where you see yourself and how you think our cooperation should look like.
> To contact me, please send an E-Mail to the "General Questions" address
> listed here:
> http://www.realthinclient.com/contact.htm
>
> Thank you for your time :-)
>
> Best Regards,
> Danijel Tkalcec, Team RTC
> http://www.realthinclient.com
Paul Breneman
Here is something similar to what we are discussing in this thread:
http://www.astromark.com/
It is basically a Delphi "browser" that gets installed on the client,
and the server dishes out page definitions and data. The Delphi browser
can create components at run-time. It seems to have a niche because the
browser does not need to be updated when your page definition changes.
You could use the same browser for many different database applications,
but you are still getting the benefit of having a real Delphi Windows
application on the client.
I don't know why it never took off...
--
Regards,
Paul Breneman
www.BrenemanLabs.com
www.TurboControl.com/TPSupport.htm - TurboPower support links
Lee Jenkins
> Hello, Developers!
>
> running inside a Browser (AJAX) just isn't good enough to become a
> replacement for todays Rich Client/Server and N-Tier Windows
> communucation for us.
>
This sounds both promising and very exciting, Danijel. I hope that
Freepascal/Lazarus is indeed included in the consideration.
--
Warm Regards,
Lee
TJC Support
>
> I have had this "crazy" idea....
Danijel,
This sounds like an excellent idea. I'm not too savvy about web apps, or
how it might play into my future plans, but conceptually it sounds like
something I might very well be able to use. I've had a business associate
bending my ear for some time about a project that he is certain needs to be
a web app running in a browser, and I'm as equally sure that it isn't a good
idea, for some of the same reasons you've discussed. While I'm not in a
position to help with the development, I'm certainly interested in the
possibility of using the product when it's done.
Thanks!
Best Regards,
Van Swofford
Tybee Jet Corp.
vavan
<r...@deltasoft.hr> wrote:
have you seen taxxi?
--
Vladimir Ulchenko aka vavan
vavan
wrote:
you may also see taxxi-baikonur "Success story" part
(taxxi.com/taxbrw/busapp.htm)
Gert de Boom
The idea of using integers to identify objects at the client location at
least will make it possible. Smart.
> Can you please spell out the possible drawback in this thread?
The major one: "doing this in Delphi is just sooo thick".
A browser-like application should at least be small and have the zero
installation feature. If I understand your idea correctly your client-app
will include all the possible components used in the application. When using
a lot of different components or even a component set like DevExpress this
will give a pretty big executable. Once some UI components (e.g. ActiveX)
need registration they will need registration on the client-side too.
I was looking into a solution like this myself, hence the interest. In my
experiment I did use the dfm's (that explains why the referenced thread took
my attention) and was looking for some way to transparently transfer events
from client-side to server-side. Your solution -using the integers- might
solve my problem.
My idea was to have a more framework like approach (a small set of
predefined form lay out components) with the generic event handling handled
by the server application itself. Any specific event-handling could then be
created using a plug-in based structure for this server application. Doing
it this way would allow me to add specific functionality (if needed) to a
generic client and server application.
I will continue to work at my application, yet will follow any progress you
make with great interest.
Gert
Kees Vermeulen (Kever-IT)
Paul,
Running a Delphi application on the Adobe AIR runtime would be
absolutely fantastic.
I share your concerns about getting yet another runtime accepted by the
industry. Even more because there are many new initiatives targeting
the same market (Google API, Adobe AIR and SilverLight). Connecting with
an existing technology will overcome this.
I'm not a Adobe AIR specialist and therefore wonder if this would
technically be possible at all?
Kees Vermeulen
Paul Hectors schreef:
Danijel Tkalcec
> Hi Danijel,
>
> Sounds interesting and I have had the same thoughts about the limitation
> of HTML and Javascript.
>
> Could you please tell me if you have considered using Adobe Flex as the
> RIA.
I have thought about using the Flash player, and about components which
could render using HTML in a Browser, but have dismissed both ideas.
> It is cross platform , has a RAD ide and has the option to compile as a
> desktop application. The Adobe Flash player I imagine is known in the
> industry and accepted. If you create your own player then I imagine it
> would need to get acceptance in the industry before IT departments allow
> it to be installed on clients.
There are already solutions that try to do this (most are Adobe powered),
but with very little success. Anything that requires a Browser to run will
be limited by that Browser. Things that build on Flex or Silverlight will be
limited by their players. But what I want is a *real* Windows Client using
*real* Delphi components on both ends, so that Delphi developers can extend
the framework with Delphi and not depend on some technology which is
entirely out of their hands.
> From what I can gather one of the main reasons why IT departments want
> browser based software is to avoid installing anything on the client.
These IT departments also blok all Flash/Flex/Shockwave content and anything
that might require an ActiveX component to be installed, so your idea would
also fall apart. If they would allow an ActiveX to be installed, then there
is a option to have a Delphi player in form of an ActiveX, started from a
Browser. This would also eliminate the need to install anything.
> I have not looked at the details but if the AMF3 specification was
> implemented in Delphi you could have binary transfer between the client
> and the Delphi backend. This avoids have to write the GUI proxy classes
> and the Adobe Flex GUI controls look like they would do the job. For
> example the Adobe Datagrid has a lot more feature than TDBGrid.
It would also mean that we would again be limiting our functionality to what
Adobe has to offer. I do not want that. The purpose of this project would be
to make N-Tier application development for Internet and Intraner easier,
without imposing limitations on what the application can do or look like,
while keeping bandwidth requirements low. From my point of view, using Flex
is not much better than using a Citrix-based solution.
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
>
> Paul,
>
> Running a Delphi application on the Adobe AIR runtime would be absolutely
> fantastic.
If you want to use Adobe, take a look at this:
http://www.adobe.com/products/flex/features/flex_builder/
> I share your concerns about getting yet another runtime accepted by the
> industry. Even more because there are many new initiatives targeting the
> same market (Google API, Adobe AIR and SilverLight). Connecting with an
> existing technology will overcome this.
Thousands of developers are using Delphi today to write Client/Server and
N-Tier Windows applications and have no problems getting their clients
installed on customers PCs. And ... if your application is good and
important enough for the customer, they will find a way to get it running on
their client machines.
> I'm not a Adobe AIR specialist and therefore wonder if this would
> technically be possible at all?
As far as I know, there is a clause in the Adobe Flex license agreement
which prohibits the use of Adobe technology for building products which
would compete with products offered by Adobe. Other than that, I think it is
possible to get access to Adobe documentation and build what you and Paul
are proposing. How much sense it would make to create a product which would
try to compete with Adobe is another question.
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
> There are already solutions that try to do this (most are Adobe powered),
> but with very little success.
To avoid someone hitting me with a bat because of this statement, let me
clarify what I mean with "very little success". I know that Adobe players
are used for writing Flash games and make the Web frontend look nicer with
animations and moving objects, but the requirements of an N-Tier Business
Application are quite different.
For the same reasons I do not waht to use HTML with JavaScript (limitations,
limintations), I choose to not use Adobe Flex or MS Silverlight. What I want
is a framework which will allow me to write real N-Tier Windows Applications
the same way I can now write Desktop Applications. I do not want the Client
to live inside a WebBrowser, I want the Client to be a native Windows
application which I can compile and extend with Delphi. If a customer should
have a problem running the Client on his PCs, we can make a small Client
"loader" as an ActiveX control which will download the Client into a temp
folder and run it as a normal Windows app. From customers POV, the client
will be running from a Browser and there will be no installation required.
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
>
> This sounds both promising and very exciting, Danijel. I hope that
> Freepascal/Lazarus is indeed included in the consideration.
I see no problem in having the client-side Framework ported to FPC/Lazarus
(RTC SDK is already being ported), but writing a complete visual and
non-visual component set for FPC/Lazarus far exceedes my abilities.
Should the developers working with FPC/Lazarus show interest in writing
proxy classes for their IDE, I will gladly assist them, but ... judging by
my latest experience with the FPC/Lazarus community, it is highly unlikely
that this will ever happen.
Best Regards,
Danijel Tkalcec
Kevin Powick
> what I want
> is a real Windows Client using real Delphi components on both ends,
> so that Delphi developers can extend the framework with Delphi and
> not depend on some technology which is entirely out of their hands.
Yes. Exactly.
--
Kevin Powick
Kevin Powick
> On Tue, 13 May 2008 14:07:44 +0200, "Danijel Tkalcec"
> <r...@deltasoft.hr> wrote:
>
> have you seen taxxi?
Interesting. I've never heard of it before. News pages not updated
since 2002. Looks like a dead product. The same appears to be true
for the parent corp "Epsylon Technologies".
--
Kevin Powick
vavan
wrote:
>Interesting. I've never heard of it before. News pages not updated
I think it's just bad marketing. it looks like it's very solid and
proven product
>since 2002. Looks like a dead product. The same appears to be true
>for the parent corp "Epsylon Technologies".
there's russian version of the site where last news entry dated with
October 5, 2005 stating that Baikonur SuperServer 3.5 released
containing small fixes. (C) notes at the bottom of the page state
1996-2007 so I believe their product is still alive and kicking
Marc Rohloff [TeamB]
> It took me from one to two days to get each of the three compononents (Edit,
> Label, Button) to get implemented and tested,
From the sample code you posted it looks like it would be possible to
automate a lot of this.
--
Marc Rohloff [TeamB]
marc -at- marc rohloff -dot- com
Marc Rohloff [TeamB]
So the only way to have code executed client side would be to compile
it into the player or client side components? I think that this would
limit the usability considerably, for example I often use custom
OnPaint and OnMosueMove events that do simple things but which would
create a lot of traffic if they require a trip to the server.
Danijel Tkalcec
> On Tue, 13 May 2008 14:07:44 +0200, Danijel Tkalcec wrote:
>
> So the only way to have code executed client side would be to compile
> it into the player or client side components? I think that this would
> limit the usability considerably, for example I often use custom
> OnPaint and OnMosueMove events that do simple things but which would
> create a lot of traffic if they require a trip to the server.
I think your requirements are very specific. If your applications are built
arround a design where OnMouseMove and OnPaint events are frequently used
and the things done are not important to the Server, then you could write a
client-side component to handle your case.
But if your users are manipulating data residing on the Server, then you
will not be able to avoid a trip to the Server, regardless of the framework
you use. What this specific Framework can do for you is to automatically
optimize all communication. For example, if your available bandwidth is too
low for real-time communication, the Client will not make X trips back and
forth, but instead wrap all the events into a single larger package and send
them to the server in one run. The resulting changes will also get to the
Client wrapped up in a single package rather than making X trips
back-and-forth.
Also, in addition to the OnMouseMove event, components will have the
OnMouseDownMove event (sample Label implementation Ive uploaded already has
this event), which would be triggered only when the user holds down the
mouse while moving. This will additionally reduce the traffic by eliminating
unnecessary events. Special components written for a special case can
further reduce traffic.
Best Regards,
Danijel Tkalcec
Peter I.
Taxxi & Superbeast is an 8 years old product that surpasses yours by
far. It has only 2 components (form and controller) and works out of
the box with 100% standart VCL.
Danijel Tkalcec
Sorry, but ... your statement seems to be based on thin air. Unless you can
point me to a place where someone can actually get their hands on the
components and do something with them, all I can see is a half-broken
website which was last updated 6 years ago.
Regards,
Danijel
Farshad
"Peter I." <n...@spam.com> wrote in message
news:0nvl245n3g5e5480i...@4ax.com...
I tried to run demos but all links to the demos are broken.
Danijel Tkalcec
I have found a few download links on their parent website (
www.psylontech.com ) with small sample projects in Delphi, but all of them
are using non-standard components which are supposed to generate HTML
content. None of the "Run Application" links work, but you can open DFM and
PAS files in Delphi and see that they are using "TEtHtml..." components and
not (as Peter said) the standard VCL (links are on the top of this page):
http://www.epsylontech.com/Demo/Demo.html
I've also found a link to download their "Taxxi communicator 3.5", which is
a 3 MB setup and requires the PC to be rebooted after setup. From what I
could see, the setup installs some MS C++ libraries. I wonder what that has
to do with Delphi:
http://www.epsylontech.com/Products/FREE_Download.html
I can't say why they have stopped offering this technology to developers,
since all of their showcases were extremely well done, but here is my "wild
guess": The company behind that Taxxi project has decided to stop offering
their components to developers after having received an offer from one of
their first supporters (partners) to license the technology for themselves.
If you follow the link to the "Eastop Computer Consultants" partner on the
page below and read the description of the technology behind their products,
you might get the same impression:
http://www.epsylontech.com/Partners/Partners.html
Regards,
Danijel
Matthew Jones
http://www.epsylontech.com/Products/Products.html actually works for pricing links.
Again an old site though.
If I may say, I think the biggest lesson to learn from Taxxi is how successful it
wasn't. Why is your version, which seems to do the same thing, going to do any
better?
The idea is certainly intriguing, but if I'm writing an app for thin client use,
I've got a few choices:
1. Use your new system. Handles the networking itself, and basic UI, but how do I
get to control the core interaction? If you select an item in a combo, I want to
disable other items based on that. If I read correctly, that now needs a round trip
to the server. If I want a particular component, say the Raize calendar selector,
then I've got to proxy that. There are a lot of issues here, and I can't see how
they aren't really all the same as IntraWeb at the end of the day.
2. I could use an established system, like Silverlight which is based on .Net so
fairly powerful, and just have it talk to the server. Technologies for this exist,
and it could use SOAP calls to do real data, but all the interaction would be in
the thin client. So I lose Delphi, but I gain all the rest of the environment like
video playback without having any hassle.
3. The last is what I'd probably go with though, if I really felt that Delphi was
the best idea. I'd use Delphi itself. If I have to deploy an app, why would I not
just deploy an app and be done? It can use the networking layer to get the data,
but it can now be much more powerful. And I can buy any component available and
start using it today, no proxy needed.
I think the only way I'd see that a Delphi proxy would benefit me is if I could use
scripting in it to make it come alive, and at that point I'm wondering why not use
the Flash/Silverlight scripting again.
I'm not saying what you are doing isn't good and interesting, but how are you going
to make it pay? These thoughts are what people will think when choosing a tool, so
you need something very compelling otherwise you'll be making a nice but not
successful product.
/Matthew Jones/
Danijel Tkalcec
> If I may say, I think the biggest lesson to learn from Taxxi is how
> successful it
> wasn't.
Are you sure about that?
I think they just did a bad job at marketing.
> The idea is certainly intriguing, but if I'm writing an app for thin
> client use,
> I've got a few choices:
You will always have choices.
And this will be a new choice.
Best Regards,
Danijel Tkalcec
Matthew Jones
I just want you to be sure it is a sensible choice!
That said, I thought that the RTC Portal with Gateway was a bad idea when it came
out, but I suspect we'll be buying it soon! I've come to realise what a sensible
method it was. 8-)
/Matthew Jones/
Danijel Tkalcec
>> And this will be a new choice.
>
> I just want you to be sure it is a sensible choice!
The choice was already made in 2004.
Except of me getting a couple of years older and becoming a dad, nothing
much has changed in my plans. I have been working towards this goal in the
past years and I see no reason not to go through with it now.
The only question is wether other third-party component vendors offering VCL
components for Delphi would follow suit and write proxy classes for their
components once I have the standard Framework and most components from the
standard Delphi palette working with the new Framework. But I guess, that is
something only time will tell :o)
> That said, I thought that the RTC Portal with Gateway was a bad idea when
> it came
> out, but I suspect we'll be buying it soon! I've come to realise what a
> sensible
> method it was. 8-)
I'm glad to "hear" that :-)
Best Regards,
Danijel Tkalcec
Adem
> too.
Some time ago, I experimented with browser plugins --mainly Firefox
plugins; i.e. NP*.DLL stuff.
Delphi does this quite well, but I had some difficulty integrating it
with the browser:
The back button was the main problem.
The browser paradigm dictates that when the user clicks on 'Back'
button to go back to the previous page, the plugin should intercept
that and manage the 'back' process.
But, unless things have changed, it was not possible --unless possibly
you modify the browser source.
This alone made the whole thing rather clumsy from user's POV.
Seconda one, IIRC, was the resizing issue: Waht happens when the user
resizes the browser. Do you resize the the stuff displayed by the
plugin (and how?) or do you let it remain fixed for th user to scroll
left-right and up-down?
In the end, I gave up. [It was something I did out of curiosity --not
for a pro/commercial need-- anyway.]
Danijel Tkalcec
>> I am sure the Client could be made available as a browser plugin,
>> too.
>
> Some time ago, I experimented with browser plugins --mainly Firefox
> plugins; i.e. NP*.DLL stuff.
>
> Delphi does this quite well, but I had some difficulty integrating it
> with the browser:
Hi Adem,
I had a different kind of a plugin in mind.
What I want to do is make a loader plugin for various browsers and not make
the whole application Player as ActiveX. The plugin would only check if the
player executable is on the local machine, update it if necessary (or
download the first time) and execute it. From the point where the player
starts, browser can be closed as it will no longer be used.
If a user clicks a back button and he came from a different webpage, the
browser will do what it always does: show the previous HTML page inside the
Browser. Should the user click the Forward button afterwards, the loader
plugin will either start a 2nd instance of the player (client application),
or it will check if the player is already running and simply do nothing.
Best Regards,
Danijel Tkalcec
Adem
> I had a different kind of a plugin in mind.
So did I :P
> What I want to do is make a loader plugin for various browsers and
> not make the whole application Player as ActiveX. The plugin would
> only check if the player executable is on the local machine, update
> it if necessary (or download the first time) and execute it. From the
> point where the player starts, browser can be closed as it will no
> longer be used.
I think I can see what you're saying:
First, you will write simple stub plugin (an ActiveX for IE or a
NP*.DLL plug-in for Mozilla beasts, something similar for Opera et al)
which will get activated on a certain MIME type.
Once activated, it will activate some other binary on the user's
machine.
Apart from the fact that you will have to educate the user to register
that particular MIME type by installing that plugin/ActiveX, there's
also the problem of starting off an exe from a dll.
A lot anti-virus sw might dislike all this.
Plus, can an exe be started from a dll and yet be a standalone one --I
mean, would it not also shutdown when/if you exit the browser? [I have
never tried this. I need someone to step in here.]
And now, on a completely different (I think) topic:
Why do you have to write proxy components?
Why not transmit just the paint data along with the event binding info
to the client in a stram like dfm or xml?
Wouldn't this make the whole client thing a lot more flexible?
Onemore thing: I think you will eventually need to incorporate a
scripting tool to the client. This will make the client much more
flexible and a lot thinner on the agregate.
Cheers,
Adem
Danijel Tkalcec
>
> Plus, can an exe be started from a dll and yet be a standalone one --I
> mean, would it not also shutdown when/if you exit the browser? [I have
> never tried this. I need someone to step in here.]
I don't know about WinExec, but using ShellExecute you can start a separate
process which will run completely independently of your process.
> And now, on a completely different (I think) topic:
>
> Why do you have to write proxy components?
>
> Why not transmit just the paint data along with the event binding info
> to the client in a stram like dfm or xml?
Because sending paint data would imply that a client is as stupid drawing
surface entirely controlled by the Server. Being such, it would need to send
ALL mouse move, up, down, wheel and keyboard events to the server for every
single thing the user does. And at the end, that would make the solution
nothing better than Citrix.
> Wouldn't this make the whole client thing a lot more flexible?
No, it would make it stupid.
> Onemore thing: I think you will eventually need to incorporate a
> scripting tool to the client. This will make the client much more
> flexible and a lot thinner on the agregate.
I do not think so. Scripting is required by the browser only because it is
very limited in functionality and can not be extended with more components.
This will not be the case with this new framework, since the client can be
easily extende with any component one may want on the Client.
Also, IMHO, even though it will be possible to write and use a scripting
component for the client, doing this will unnecessarily complicate things
for the developer, as he would again need to split his thoughts in
client-side and server-side code. And that is the main thing I want to
avoid. How I see things, there is really no need for this when you can
extend the client with more powerful components to handle your tasks. The
developer using the framework should not need to split his code in two
categories (client and server), but simply use the components as if he would
be writing a desktop application. This will not only reduce the development
time, but also make the code much easier to maintain.
Cheers,
Danijel
Peter I.
<r...@deltasoft.hr> wrote:
>Sorry, but ... your statement seems to be based on thin air. Unless you can
>point me to a place where someone can actually get their hands on the
>components and do something with them, all I can see is a half-broken
>website which was last updated 6 years ago.
>
>Regards,
>Danijel
Hi Danijel,
4 or 5 years ago I try sucesfuly a demo of their product (public demo:
download & connect to beast server). And it was really impresive, it
acts just like a real desktop aplication.
The point here is that they don't rewrite every VCL control. I think
that this could be a profitable idea in your actual stage of
development.
And best wishes with your project!
Danijel Tkalcec
>
> The point here is that they don't rewrite every VCL control. I think
> that this could be a profitable idea in your actual stage of
> development.
Hi Peter,
there are several ways to implement remote funtionality similar to what I am
proposing here. Developers who wrote that Taxxi project could have had the
goal to not have to write proxy classes for visual components and use most
of the components from the standard Delphi components palette, which I also
know can be achieved by using a single method on the Form which will
enumerate through all visual components and compare the last state of
components properties with the current state, then send the difference to
the Client, but ... that method also requires that this enumeration and
comparison process is done for every event triggered on the Server-side,
which will result in highly increased CPU and memory usage Server on the
Server when compared to the method where components themselves (through
their properties and methods) prepare the data. It also implies that all
visual components features are entirely defined by their published
properties. While this may be the case for some visual components, it
definitely is not true for all visual components.
On top of that, this method limits the developer in what he/she can do with
the components at runtime. For example, components where the developer would
use methods to "draw" on a canvas would simply not work, since these methods
would go by unnoticed if there would be no changes to the published
properties.
So ... yes, a similar framework could be written which would not require
proxy classes for all visual components in use, but that framework would
also have considerable drawbacks compared to what I want to do. IMHO, it is
better to have developers (who understand how each component works) write
proxy classes for the framework to make sure that everything runs as
intended while CPU and Memory usage are kept low, than to have a
semi-intelligent framework trying to reduce the amount of coding by running
comparisons of all components properties after every event.
> And best wishes with your project!
Thank you.