I am developing a project for the end of my studies. This project is basically acting as a server, is cross-platform and developed in C++.
I was wondering if it was possible to make a web interface that could be used like for instance the listener design pattern to log what the program does. This would be cross platform, and is ideal since the program is supposed to run on a distant server.
My question is: is there any web technology to could let me update my web page live when the program logs something. I know this is something unusual and I'm not an expert in web technos, that's why I am asking.
Would Erlang do it ?
Thanks for your help
EDIT: To give a more concrete example, I would like to be able to follow the execution of my program live and see the logs of my program appear on the page. The idea would be to use a web page like I would use WPF on Windows or GTK on Linux for instance. Like someone said, it would be some kind on monitor for my application.
It's much easier than you might think. A web server basically gets a request as a path name, and returns a page. If you set it up correctly, it will invoke a program to create the content. This is called "CGI".
If you can do it without live updating, it's then super-easy: just refresh the page and your program can be called again.
If you want live updating, you'll need to do a little more. The easiest way is with a little lightweight javascript. The magic word here is AJAX. There are a number of tutorials on line for both of these, just google.
The main thing is to start with a very very simple example and add to it. Javascript in particular is a little peculiar; follow the tutorials, though, and you'll get it.
You can embed a web server such as http://code.google.com/p/mongoose and poll it using xhr or better use websockets.
Or use a monitoring solution such as Nagios (Nagios Core is free).
Related
I have done a lot of searching to find a way to start a GUI application from a windows service on Windows 7. Most of what I have found is that with Windows 7 services now run in a separate user session and can not display any graphical interface to the current user. I'm wondering is there is any kind of workaround or different way of accomplishing something like this? Can the service start a process in a different user session?
This change was made for a reason and not simply to annoy developers. The correct approach is to put your UI in a different program and communicate with the session through a pipe, or some other IPC mechanism. The recommendation that services do not present UI is more than 10 years old now.
You should really try to follow these rules, even though it may seem inconvenient to begin with. On the plus side you will enjoy the benefit of keeping your service logic and UI logic separate
If your services runs under the LOCALSYSTEM account then you can check "Allow service to interact with desktop", for the benefit of legacy services that would fail if they could not show UI. But it won't help you anyway because the UI will show in session 0 where it is never seen!
I recommend you take a read of the official Microsoft document describing session 0 isolation.
There is a way to do this.
If you need to show a simple message box you can use the WTSSendMessage Routine.
If you need a complex UI elements you can put it in a separate program and you need to use CreateProcessAsUser Routine.
In this sample provided by microsoft you can see the process.
http://blogs.msdn.com/b/codefx/archive/2010/11/26/all-in-one-windows-service-code-samples.aspx
Windows 7 introduced what is called "Session 0 isolation" that in practice means that every service (except system services) run in a separate non-interactive session. For this reason you cannot directly create a GUI from within the service, except if you run in legacy mode by flagging the Interact With Destop option, which is not good if you plan to run your service for some years in the future.
As David Heffernan said, the best is to use a client-server architecture. WCF makes it easy to communicate with named pipes.
This page is a good starting point to read about Session 0 Isolation and this white paper is also very good.
I looking for some advice on the best way to set up a project. Not sure if this is the right place to ask but I will give it a go.
I am looking to create a "Smart Mirror". I know there are options already available for this but I want to go through the process of creating my own.
I have created the UI using electron and I am using this on a raspberry pi 3b+ using raspian stretch.
Now this is where my knowledge is lacking, due to no experience and not sure if what search terms to look for.
I would like to create a plug in on Chrome(used on my mobile phone) or a process that runs separately, to say "Send page/video to Smart Mirror". What I envisage is that this plug in will copy the URL for the page or the video and send this via a web service call. The running electron app on my raspberry pi will receive this call and process the URL and then display the page/video within a portion of the application.
I have only ever consumed a web service from within an application.
I am not sure how to set this up. Can my electron app be set up to receive this call? If so what search terms should I be looking for?
I hope this makes sense.
Please let me know your thoughts or if I am thinking about this all wrong
i am writing an program in c++ and i need an web interface to control the program and which will be efficient and best programming language ...
Your application will just have to listen to messages from the network that your web application would send to it.
Any web application (whatever the language) implementation could use sockets so don't worry about the details, just make sure your application manage messages that you made a protocol for.
Now, if you want to keep it all C++, you could use CPPCMS for your web application.
If it were Windows, I could advice you to register some COM component for your program. At least from ASP.NET it is easily accessible.
You could try some in-memory exchange techniques like reading/writing over a localhost socket connection. It however requires you to design some exchange protocol first.
Or data exchange via a database. You program writes/reads data from the database, the web front-end reads/writes data to the database.
You could use a framework like Thrift to communicate between a PHP/Python/Ruby/whatever webapp and a C++ daemon, or you could even go the extra mile (probably harder than just using something like Thrift) and write language bindings for the scripting language of your choice.
Either of the two options gives you the ability to write web-facing code in a language more suitable for the task while keeping the "heavy lifting" in C++.
Did you take a look at Wt? It's a widget-centric C++ framework for web applications, has a solid MVC system, an ORM, ...
The Win32 API method.
MSDN - Getting Started with Winsock:
http://msdn.microsoft.com/en-us/library/ms738545%28v=VS.85%29.aspx
(Since you didn't specify an OS, we're assuming Windows)
This is not as simple as it seems!
There is a mis-match between your C++ program (which presumibly is long running otherwise why would it need controlling) and a typical web program which starts up when it receives the http request and dies once the reply is sent.
You could possibly use one of the Java based web servers where it is possible to have a long running task.
Alternatively you could use a database or other storage as the communication medium:-
You program periodically writes it current status to a well know table, when a user invokes the control application it reads the current status and gives an appropriate set of options to the user which can then be stored in the DB, and actioned by your program the next time it polls for a request.
This works better if you have a queuing mechanism avaiable, as it can then be event driven rather than polled.
Go PHP :) Look at this Program execution Functions
I want to build the following back-end service:
For each call to the service, spawn a web browser that loads a webpage (including flash) and returns a screenshot of the page to the caller at intervals (ie every 3 seconds) until the caller disconnects. This needs to scale for many callers (thousands perhaps), each of which needs its own browser session.
When I decided I needed to build this program, I was surprised that I had basically no idea how I could do it.
On stackoverflow, I found the following link which looks promising: http://www.genuitec.com/about/labs.html
Any other ideas?
You can use XULRunner (Mozilla engine) on your server side. I'm in doubt though that this solution is scalable.
I develop industrial client/server application (C++) with strong real time requirements.
I feel it is time to change the look of the client interface - which is developed in MFC - but I am wondering which would be the right choice.
If I go for a web client is there any way to exchange data between C++ and javascript other than AJAX <-> Web service <-> COM ?
Requirements for the web client are: Quick statuses refresh, user commands, tables
My team had to make that same decision a few months ago...
The cool thing about making it a web application would be that it would be very easy to modify later on. Even the user of the interface (with a little know-how) could modify it to suit his/her needs. Custom software becomes just that much easier.
We went with a web interface and ajax seems the way to go, it was quite responsive.
On the other hand, depending on how strong your real time requirements are, it might prove difficult. We had the challenge of plotting real time data through a browser, we ended up going with a firefox plugin to draw the plot. If you're simply trying to display real time text data, it shouldn't be as big an issue.
Run some tests for your specific application and see what it looks like.
Something else to consider, if you are having a web page be an interface to your server, keep in mind you will need to figure a way to update one client when another changes the state of the server if you plan on allowing multiple interfaces to your server.
I usually build my applications 2-folded :
Have the real heavy-duty application CLI-only. The protocol used is usually text-only based, composed of requests and answers.
Wrap a GUI around as another process that talks to the CLI back-end.
The web interface is then just another GUI to wrap around. It is also much easier to wrap a REST/JSON based API on the CLI interface (just automatically translate the messages).
The debugging is also quite easy to do, since you can just dump the requests between the 2 elements and reproduce the bugs much more easily.
Write an HTTP server in your server to handle the AJAX feedback. If you don't want to serve files, create your server on a non-standard port (eg. 8081) and use a regular web server for the actual web page delivery. Now have your AJAX engine communicate with the server on the Bizarro port instead of port 80.
But it's not that hard to write the file server part, also. If you do that, you also get to generate web pages on-the-fly with your data pre-filled, if you want.
Google Desktop Search does this now. When I search my desktop for 'foobar', the URL that opens is this:
http://127.0.0.1:4664/search?q=foobar&flags=68&num=10
In this case, the 4664 is the Bizarro port. (GoogleDesktop serves all the data here; it only uses the Bizarro port to avoid conflicts with any web server I might be running.)
You may want to consider where your data lives. If your application feeds a back-end database, you could write a web app leaving your c++ code in tact -- the web application would be independent and offer up pages to web users and talk directly to the database -- In this case you have as many options, and more, as you have indicated.