I look like having a requirement to access a SignalR hub with a Delphi client.
How do I implement a basic SignalR client in Delphi?
More generally, where can I find an up to date description of the protocol?
Traffic load will not be high, so it doesn't have to be extremely clever or anything.
[Edited to make it less of a "recommendation" question.]
Partial answer to question: I found useful, low level version of the documentation in a legacy zip of version 1.3
It has since vanished from the signalr git repository, and I've been unable to find a newer version online anywhere.
I have popped it here for convenience.
http://www.mithril.com.au/SignalR%20Protocol.docx
This document describes the protocol at a suitably low-level for me to feel confident I can construct a partial implementation of SignalR using existing components, sufficient for my purposes anyway.
If a more up to date version of this exists anywhere, I'd appreciate a link.
Related
First of all what I want is quite complex, at least for me, but on the other hand it sounds exciting.
I have a software written in delphi, and I want a real time web based client for it.
The requirements:
On the client side pure Javascript
Shiny interface ( GWT, SmartGWT )
Asynchronous connection between the server and the client. Ajax push, Long Polling, Comet, WebSocket?
On the server side
scale-ability
On the delphi side I think I could use ICS from Overbyte, to handle the requests. I know that THttpAppSrv from ICS pack can easily serve simple content, but what about Websocket, or how can I do long polling with it?
What do you think, is it a good combo ( GWT, SmartGWT on the client side, and ICS on the delphi side ), is there any sample project out there, or is there any other solution?
Update
Thanks for the useful comments, I think I get closer to the solution. It's good to know that GWT can use a custom server, however I think Arnaud is right, GWT with it's own Jetty server is a complete solution, but unfortunately not for me. :) I think I need a server written in delphi, which can communicate with GWT RPC.
Update 2
I accepted Arnaud Bouchez's answer which looks me the best for the original question, however I think there's a better solution (if you change the requirements a little) for creating a client running in the browser for a delphi application. I just make a little comment here, to share the idea. Finally I used a node.js server, and connected it to my delphi app with the help of ZMQ.
About the HTTP server on the Delphi side, consider using the kernel mode http.sys server provided by Microsoft since XP. Should be faster than ICS.
For the AJAX part, take a look at Op4JS or up to come ElevateDBBuilder.
What is great with those solutions is that you can write object pascal code, and that this code will be translated to JavaScript. Not yet finished, but worth waiting a little for their release time.
Of course, more classic AJAX solutions do exist, like IntraWeb or ExtPascal. Both implement their own web server.
About GWT, AFAIK they are java libraries, deeply linked to the Java world. You won't be able to make it work with Delphi.
Edit about GWT:
GWT is a full Client-Server framework.
If you go with GWT, I suspect you'll end with a full Java rewrite of the application at some point. Or you'll miss most interest of GWT as a framework. It's your choice.
I'd rather rely on some more standard approach, using JSON for communication for instance as we do with our framework.
Have you checked out Intraweb? I have not used it extensively myself - but it seems to be quite popular for Delphi web apps.
I have made several Web Apps using TWebBroker with either IIS or Apache. It is Asynchronous, and allows you to easily port/share Delphi code with your other application. And it would support Ajax calls.
Delphi, pure javascript on client side and shiny interface? You're talking about Unigui!
I worked on PHP, ASP and Cold Fusion before, and wanted to do (almost) the same with Delphi. I started xxm. It has Delphi and HTML code in the same files, and (re)compiles a library when you hit refresh in a browser. I've made handlers for these libraries so you can run them in IIS, Apache, InternetExplorer, Firefox, or straight from a Delphi-based HTTP implementation. (I started work on a http.sys handler also, but that'll take a lot more work.)
Also, in relation to your question, I wanted streaming, I wanted that what I output would get transferred ASAP to the listening client, so you could do long running pages, long polling, and the like. As for GWT and other client-side script, I've successfully used prototype and jquery.
I read this question but was somehow not satisfied with the answers.
I also quickly read (as suggested in that question) the last chapter of Marco Cantù 2010 Handbook, from which I quote the following (I think I can quote such a short text):
I [Marco Cantù] do have a lot of
investment in server side web and REST
applications written in Delphi, and in
the recent years I've started playing
with and introducing at conferences a
Delphi Web Application REST
Framework119 (that is, DWARF), which
at this time is still not publicly
available... simply because it is too
sketchy and unfinished to be
published. I've seen other ongoing
efforts to clone Rails in Delphi and
offer other REST server architectures.
I think that if you want to build a
very large REST application
architecture you should roll out your
own technology or use one of these
prototypical architectures.
Considering that I own Delphi XE Professional and DataSnap is not in there and I would like to consider to write large applications too according to the above comments it seems DataSnap is not an option.
Is there even a commercial solution for this? I don't want to consider "my own implementation of REST", I would like to create a webserver that uses some of my datamodules where I use the DAC I choose (Devart in this case).
Final note: my goal is to write the backend for a large web application, on the client I would like to use Ext JS 4.0, but I want to do all the client work in javascript, to take full advantage of EXT JS, so basically I need a webserver just for the data and tracking the state, not for serving webpages.
To create your REST services, try our Open Source mORMot project. Now it is a well known and stabilized project, used world wide in production.
You can use any DAC with the current state of the framework by implementing a custom TSQLRestServerStatic class (similar to the TSQLRestServerStaticInMemory class, but calling your DAC): so you'll benefit for the ORM and the JSON RESTful architecture, together with the high-speed http.sys kernel-mode server.
The SQLite3 engine is NOT mandatory with our framework, even if it was designed to work better with it.
If you will start an application from scratch, I think the mORMot is a good option if Delphi is your only option. If you choose datasnap you'll have to live with the problems of performance and stability.
I wrote an article on my blog talking about performance and stability with DataSnap (and mORMot) in large applications, you can see it on the following link:
DataSnap analysis based on Speed & Stability tests
I think you should have a look at kbmMW, there is a way to implement a basic REST server based on an event driven HTTP server.
Check news.components4developers.com news groups, there you will have a lot of documentation.
FireHttp is a high-performance Web server based on Delphi/Object Pascal language. It supports HTTP 1.1, HTTPS (SSL/TLS), WebSocket, GZip, Deflate, IOCP, EPOLL. It adopts multi-process+multi-threading model, has good stability and concurrency performance, and provides SDK source code. Developers can use SDK to quickly build high-performance cross-platform Web applications.
For example, are they using Java/Struts? Or ASP.NET? Or PHP? Or some combination of technologies?
Not sure how public they are about their infrastructure, but it would be very interesting to know what they use.
Not sure if this is what you are looking for, but see here: http://en.wikipedia.org/wiki/Second_Life#Technology
As is often the case with such questions, High Scalability has an overview of the Second Life architecture, plus links to presentations by SL staff and other resources.
I will take a wild guess, a combination of scripts running on a server written in C++.
While this is an antique question, I'm surprised that no one mentioned OpenSimulator or some other Sim application. OpenSimulator will allow you to run your own Second Life clone on your own hardware and with one of the many SL viewers that are out there, you could just connect to your own virtual world. And this World would be very similar to SecondLife, including it's scripting language!
OpenSimulator is written in C# back in 2007 using the Second Life Protocol to be very identical, although they don't strive for complete compatibility.
The Firestorm Viewer is also open source as Linden Labs once published the source code of their viewer using an LGPL license. But the Firestorm team doesn't make access to the source code easy to find. (It is here!) You will need to know C++ to understand the code.
So, Second Life is made from three parts: Server, client and a special protocol that goes in-between. As Second Life is old, it also uses some older techniques and protocols as developers generally don't fix things that aren't broken. Then again, this question is also old and I'm not even sure if anyone is still interested in Second Life.
Still, if someone is still interested then this gives some nice additional information.
I never liked components for winsock programming,I loved it in its natural way,but today my collegue told me to use Indy for my project.Could you tell me if Indy better alternative for my project?
-2 TCP servers,2 TCP clients.4 sockets total
-The project is a proxy.
And now the second question,I read daily that WSAASyncSelect is not good and that's predictable,it's from winsock 1.1.My question is: Suggest something better than AsyncSelect for winsock-by-hand.
Thank you.
My preference tends to lean on synapse for all of my socket work because of its light and easy to understand approach. It is not a component architecture, but a class architecture and implementation is generally as simple as copying one of the existing helper classes and modifying it to perform the exact steps needed. Synapse also has a great user community, and is being actively developed so get the latest changes from the svn snapshot (I believe its revision 98, the website has a zip of revision 38).
Yes, Indy is much better because it provides you with consistent abstraction of winsock communication. The difference is like creation windows using WinApi and simply using TForm.
Yes, Indy is better. So is ICS, or Synapse, or any of the other internet-related component sets. They handle all of the minutia and let you work on your application's actual functionality instead of wasting your time on the communications layer details. They're also much more well tested (because of the broader user base and wider range of hardware and operating systems) than your own code could ever hope to be.
NIH (Not Invented Here) is a really bad idea if there are well-constructed, well-maintained, and widely used alternatives available, especially when those alternatives are free with source (like Indy and ICS).
So far, no Delphi version supports SOAP 1.2 clients or server.
I have tried for weeks to make it works, but every time a new problem, with VS/C# I could do the same, and make works in 3 days, but I need to do with Delphi 2009.
"I write a new version using Rem Objects SDK,", but the result was not better that I had with Delphi SOAP library.
But I'm wondering what choice else do I have, which library/component full support SOAP 1.2?
I found a message from Bruneau, suggesting Pocket SOAP
http://www.pocketsoap.com/pocketsoap/
I don't know how this works, Ill investigate and see what I can do.
Remember to vote for SOAP 1.2 support on codegear's QC:
http://qc.codegear.com/wc/qcmain.aspx?d=66864
Currently, it's voted the #2 report for Delphi (after 64bit support). I'm really sure that CodeGear is not going to ignore this.
Follow up. This has been implemented in Delphi 2010.
I suggest that you dig into the source. With Delphi 7, I was able to add all sorts of extras by copying the SOAP code into my app's folder and editing it carefully. In one case I did some string manipulation to adjust the incoming SOAP packet to make it work with the way Delphi worked. I've not had to do this with RemObjects yet, but you do get the source for that too. Plus they have active newsgroups you can ask questions on.
In some cases I found it much easier to write a proxy SOAP service in C# and VS, and consume it from Delphi with a simplified service description (WSDL). In the long term it was the most efficient solution, without any problems regarding stability or performance. The SOAP support in Delphi is not one of its highlights.