Related
I am building a server-client application that involves heavy signal processing (e.g. FFT). I have a working application written in C++/Qt, where everything (signal processing and other calculations) is done in client and server just sends raw data. Now I feel it would be easier to implement these features on the server. So, that maintenance becomes easier.
As I am doing signal processing, I think I should stick to C++ for performance. But I am open to new ideas.
Constraints:
I need type checking so javascript is out of discussion.
Scaling includes adding more server and each server will have at the max
10-12 users. So, Hardware cost is important. I cannot use x number of
i7 processors.
No option of using cloud services.
So, right now my question is as follows:
How can I create web services using C++ for Linux server? (Although cross platform is not important, I would appreciate if I can achieve it.)
EDIT [02:09:2015]
Right now, I think the choice is between poco and C++ Rest SDK. I feel I should go for C++ Rest SDK. Mainly because it has only those features that I need. And Also it is supported by microsoft and uses boost internally. So, I feel in future, this might be well integreated with standard.
You could use cross-platform Poco library to implement HTTP server, it is really straightforward with this framework, and they have a lot of examples. You can also use JSON serialization (like rapidjson library) to implement REST service on top of HTTP - this way your Web service will be accesable by most of the modern Web frameworks.
You might want to take a look at the C++ Rest SDK, an open source, cross platform API from Microsoft.
Like #nogard suggested, I also recommend POCO for now. It's the most serious and feature-full solution. Given you mentioned Qt, I suggest you to take a look at Tufão.
EDIT:
I forgot to mention one comparison of mine on the C++ HTTP server frameworks.
If you directly handle HTTP requests, you might loose the functionality what Web Servers does well what it was build to do. I had a similar issue, what I did was wrap up my Qt c++ code inside a PHP extension. In your case you can do the same. Wrap your logic inside what ever technology you are about to use, doesn't matter it's PHP, net , Java or anything else.
I have an interesting conundrum. I have been challenged with identifying the most suitable process in which to create a "browser front-end" to an existing multi-user application built within the TigerLogic/Pick D3 environment. My research indicates there are many ways to do this; but I am struggling to decide which method is best or where to start. I have "played" with a few technologies but a commitment to one is needed to get started.
These methods include:
Creation of a complex webservice using MVS Toolkit; and engineering a client from WSDL either from scratch or using maven/wsimport. Tests indicate there is a lot more to this process than originally though for a simply WSDL.
Development of a Java based web app that harnesses the MVSPJavaAPI - I am not a JAVA developer so this means learning a new language. Development would most likely take place in Eclipse.
Using TigerLogics FlashCONNECT - resulting in additional expenditure to clients so not preferable - and more or less ruled
out.
There is also the .NET option - but I have ruled this out on the basis of needing portability.
My question is, has anyone else out there done anything like this and could you share your experience? My first task is to build a web-app that will reliably give me the D3 TCL prompt in a browser that I can customise.
I am not sure there is a definitive answer here but would like peoples thoughts and will label the most useful as the answer.
What path you choose depends in some part on your existing skill-set and whether that fits in with your portability needs. It is very difficult to give you a concrete answer to your question becaue of not knowing in which part of the chain you need the portability.
It is however possible to develop a web-browser front-end using .NET which will run on Linux or Windows, so I don't see an issue with portability here. Your web server will have to be windows based but it shouldn't matter whether D3 is running on Linux or Windows at the server-end, or whether the client desktops are running Linux or Windows.
You could try TigerLogics MVSP .NET API but I do not know if it has the power to deliver based on your needs. I believe you may find mv.NET from Bluefinity could fulfill your needs. This is in my opinion the leading product on the MultiValue market for achieving the goals you have in mind. This will mean spending money of course. For this you will get a very powerful set of tools. Also, the cost of investing in a good tool could end up smaller than the cost in terms of time, effort and potential complications of trying to do this piecemeal without spending any extra money. I am sure Flashconnect would also do the job. You would have to weigh up the cost of the different options to find out which one is right for you both technically and financially.
Not knowing whether or not you have .NET in your skill-set, I don't know whether the .NET option would be easier for you. It is however technically possible.
I would suggest using Rocket's D3 (formerly TigerLogic D3) .NET APIs and create a Web API RESTful service that you can consume with JavaScript in any other web technology and if you need to call from a D3 subroutine (in case you would) then use the MVS Toolkit.
Requirements though are D3 9.0 or later.
I've used all of the technologies described, and many more to interface with D3. I agree with #Glenn and will add... I understand you're edging away from .NET. That's fine, you don't need it. But consider that most LAMP implementations separate the DBMS servers from the web servers. That topology introduces short delays between the tiers but decouples them in case you want to use multiple web servers or multiple databases - a common topology even with D3 / MV.
I have a client where we have a Java/Grails front-end over Linux, with all data queries filtered through a single, elegant data provider class that's abstracted from application logic. That uses a web service call which I wrote in Java, calling to a .NET web service. The service is easily generated/modified, as is the client from the WSDL. From there IIS carries inbound queries to D3 via mv.NET, and at this point it doesn't matter if the D3 DBMS is in Linux or Windows. My web service could have as easily been in Linux with Java but it would then lack a pooling mechanism - see below.
If you want all Linux then you can go with the MVSP Java library. TigerLogic (now acquired by Rocket Software) committed to a PHP binding for MVSP some months ago. Rather than wait, one of my clients created a PHP wrapper around mv.NET, though MVSP is as easy. So the resulting application is essentially LAMP, but with the M = Multivalue. I have written code like this too - we can write a wrapper in any language which exposes a useful API and abstracts both connectivity method and OS dependencies. In other words it doesn't matter what languages we want to use or what OS's are involved. That part is rather trivial and subject to change later. It's better to focus on the application than the communications.
You can also go off the menu, so to speak, and create your own Java/PHP wrapper around the OS-level d3tcl command, which is a script/wrapper around the d3 executable. This allows you to open a connection yourself and pass in commands.
Whatever option you select, you need to consider that opening and closing a DBMS connection is a slow process. You do not want to script a login around every data request. You do want to open a connection and keep that open persistently, while your client code accesses and releases that persistent connection as required. This is why we like mv.NET and FlashCONNECT. With MVSP and other mechanisms you need to create your own persistence model. You'll also need to manage a pool of connection resources - what happens when you get 10 simultaneous queries, or just 1 short one after one long one? You don't want queries to back up, you don't want to reject or timeout connections, and you don't want to fire up a connection for every client. You do want the proper number of DBMS sessions waiting for inbound connections. mv.NET and FlashCONNECT do this for you, the others do not.
Personally I'd shy away from FlashCONNECT. I was there for its initial development and testing and for years of end-user implementations. It's not as widely used as the other options and is more a tool for those who aren't familiar with other options. If you're talking about Java then you're probably not inclined to use FlashCONNECT. That said, if you have developers who are not familiar with anything outside D3 then FlashCONNECT is a decent server-side tool for them while someone else is focusing on the client-side with other technologies. Everyone should use their best skillset.
Finally, (already?) if someone is not familiar with external technologies, and more intimate with D3, then other options exist like DesignBAIS and Viságe, mostly removing the burden of communications and allowing developers to work on the client-side features and back-end rules in BASIC.
I discuss all of these topics plus mobile and telephony on my blog.
HTH
For a current project, we're designing a client desktop application that parses text files and interfaces with a web based database.
So far we've split the project into parts:
(Third-Party Program) -> (Our Desktop Client) -> (Our Parsing Library #1 and #2) -> (Our Web Server) -> (Our Verification Library) -> (Our Database)
We've hit confusion when it comes to choosing the correct way (and the best language) to make these pieces work together.
The third-party program's output is a simple text file, and we're just parsing it into a SQL-esque format for insertion into our database after verifying the numbers are in a certain range.
The first question we have is regarding the client language itself. We're planning on writing the parser libraries in C++ as they're just mostly text management. Our desktop client needs to be cross-platform for Windows and Mac. Currently we're leaning towards writing this in Java using Swing and the JNI. However, we realize there's a lot of hate for Java and that we'd have to worry about bundling in the JRE.
Is Java a good choice in this situation? Our other options seem to be writing this also in C++ using something like Qt for the GUI, or going platform specific and writing the windows version in .NET and then a Mac specific version. Our Windows community is the vast majority of users.
Our second issue is connecting this client with our web server. Originally we were just going to use an http POST to upload the file. We could also FTP the file which seems like overkill. We started to explore web services but were not sure if a web service could handle large amounts of text data.
Is there an easier way to do this? Everything is text, so it's no problem to send them in chunks or one giant string. If we go the web services route, will that effect our language choice for the desktop client?
There are definitely hundreds of ways to handle something like this, but most of these concepts are new for us. Any suggestions would be greatly appreciated.
Qt is an excellent choice and as it's native C++ it will be easy to integrate with your parsers too. Why write two versions when a single Qt version will run fine on both platforms with native look and feel? Depending on the license you choose you can even statically link Qt if you're concerned about deployment complexity.
A web service would generally have no problem handling large amounts of text and pretty much any language will interact with it easily assuming basic network I/O functionality. Depending on the language you will probably be able to find libraries that do most of the work for you, assuming it's not already supported natively.
As you say, there are many different ways to do what you want to achieve. There is no right or wrong way but obviously some designs will suit your needs better than others.
I want to create a web application that runs with very little RAM and I think C++ can help me achieve that.
Now, many people say C++ is unsuited for web development because:
there is no easy string manipulation
is an unsafe language (overflows, etc)
long change / build / test cycles
etc.
But I'm sure the C++ community have found ways to alleviate all those (maybe not the compile time) however since I'm not a regular so it is hard for me to put a value on what I find in Google.
So I'm asking for some guidance. I would appreciate if you share what works, what tools/libs are current and alive. What strategies can help with web dev in C++? FastCGI or embedded server (Asio / POCO / Pion / etc.)? How do you address security concerns?
Thanks a lot for any help
Have you looked at http://www.tntnet.org/. They have created a... well let me cut and paste from their website:
Tntnet is a modular, multithreaded,
high performance webapplicationserver
for C++. To create webapplications
Tntnet has a template-language called
ecpp similar to php, jsp or mason,
where you can embed c++-code inside a
html-page to generate active content.
The ecpp-files are precompiled to
c++-classes called components and
compiled and linked into a shared
library. This process is done at
compiletime.
I've used it and it has quite a small overhead plus it has screamingly fast dynamic page generation. Makes PHP, Ruby etc snails in comparison because with tntnet you are running compiled C/C++ code.
There's the Wt Project. It uses a paradigm similar to Qt's signals/slots.
There is nothing wrong with trying to build a web app in C++. It's actually a lot of fun. What you need is a:
Templating system
A CGI lib
A database API wrapper, most likely, to avoid dealing with something like the low-level MySQL API
A logger
ATL Server is a library of C++ classes that allow developers to build internet based applications.
ATL Server. It's open source too! And of course there is always ISAPI. Ah, the bad old days. :)
In your other question you mention that your embedded system is openwrt. As this router firmware already comes with a embedded web server (for it's administration UI), why don't you use that for you app as well?
Our web app backend is in C++ via CGI and we use Clearsilver templates along with the HDF that comes with it.
Give us some more hints about what you're trying to do.
You can write a good old-fashioned cgi program in C++ easily enough, and run it with FastCGI. We used to do that all the time.
You could write a C++ program embedding a lightweight HTTP server as well.
Both of them are much bigger PITAs than using something like perl or ruby.
So for why C++?
Update
Okay, got it. The main thing about FastCGI is that it avoids a fork-exec to run your CGI program, but it is a little bit different API. That's good, but you still have the problem of handling the HTTP stuff.
There are, however, several very lightweight HTTP servers, like Cherokee and Lighttpd. In similar situations (building web interfaces for appliances) I've seen people use one of these and run their C/C++ programs under them as a CGI. Lighttpd in particular seems to concentrate on making CGI-like stuff fast and efficient.
Another update. I just had cgicc pointed out to me: http://www.gnu.org/software/cgicc/
That might solve some problems.
You can try Cutelyst a C++11 built with Qt, with one of the best positions on TechEmpower Benchmarks.
Even though it requires Qt 5.6+ a full CMS (CMlyst) uses around 6MB of RAM while serving around 3000 requests per seconds on a single core.
And for your string manipulation issue QString is just an amazing class for that.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As a novice, I've spent time learning a smattering of C and a fair bit of PHP. I've looked at writing desktop applications for Windows, but there seems to be a fair barrier to entry due to complexity of APIs. Is it worth learning this, or will native applications become less common in the future?
The way I see it, the only desktop application I ever use is a web browser and a text editor as well as the obviously the OS itself. Everything I need is online now.
Is learning to write non-web applications a useful skill going forwards? If so, what should I learn?
I don't think it is ever a good idea to choose one side and stick with it religiously. I think a good engineer will expose themselves to as much as they can so he can make an informed decision about which is the best tool to complete a task.
In other words, don't choose a platform, OS, programming language, etc. and then ignore the others. It is best to be well-rounded in your skill set.
There will always be a market for native apps, although a lot of stuff is moving to the web and there's more scope than ever before for web based apps, native GUI applications are never going to go away entirely.
However, it's really, really hard to give you any really useful advice other than stick with what you like. If you use web stuff exclusively, it would be a bit foolish to go and become a windows GUI programmer :)
This may get modded down - but I'm going to say it anyway.
You can either program or you can't. About 18 months ago when I was looking for a new job, I was looking at the market and I was doing a lot of .NET but a few places wanted me to do JAVA.
I was doing Web Services, they wanted someone to do other stuff...At the end of the day it came down to this - if you know how to code you know how to code. If you're writing desktop apps right now and say in 6-8 months you want to move to some ASP.NET MVC, you'll be fine.
It may take you a bit of start-up time to learn the syntax and get a feel for some things - but in the end you'll be fine. I say this holds true for all the new languages...Skill is skill
Non-web applications will be very useful for the far future (as I see right now). We will not be able to do anything with the efficiency as a well written desktop application online using an interpreted scripting language that has to use a network protocol to communicate with the client.
However, if you are interested in networking, maybe you can try a little of both. Make an rss reader, a simple web browser, or an IRC client. Their all great projects.
You should learn whatever you want to learn. If you don't you'll probably find it harder going than you need to.
I personally started writing desktop applications for Windows, because I used it at the time. These days I do think that you're correct - you can produce a website / online-application without investing so much into the process.
But even writing a decent web application is going to be hard if you're new to programming. A standalone page is simple, but when you add databases, security, and administration into the mix then things can grow.
In my oppinion, a novice should conentrate on the basics and internals of the language of choice. Graphical or web interfaces should wait until you know what you're doing in the backend. I personally would suggest you start with console programs, but I guess that depends on the platform you're using. Maybe desktop interfaces are easier to start with on Windows.
The best practice (in my oppinion) is to write a solid backend with the functionality you want to provide and write it in a modular way, so you can later decide if you want to provide a desktop interface or a web interface (or both). The choice for the user interface shouldn't matter in the beginning.
Learning non-web applications will always be useful. There will always be applications that are not suited to be web apps. Even if everything moved to be a web application, the server side code and web browsers still need to be written.
At this point in time, if you're interested in the Windows platform then I would advise looking into C# and WPF. Those technologies are used in both native and web environments.
Web development is all well and good but the majority of systems even if they have a nice web front end still consist primarily below the web level, a bit like an iceberg.
End most web implementations are n-tier in design with the lower levels like data access and integration with peer servers ocurring in non web languages.
As I see it there seems to be one pervasive language that can touch all these levels and than is .Net Framework. Notice I make no specification about c#, vb etc. I consider that to be a matter of taste. However I can't remember seeing an n-tier banking website using php to do the data layer. Nor an online ordering website that would use ruby to talk to its jd edwards server.
This is where the heavyweight languages still pervade and if thats where you want to work then learning the .Net framework in whatever language variant you choose is the way to go.
Master one discipline then move to the next one.
I am also at the very infancy of learning business application development. The very step I took was to study database. Majority of the applications in the real world is data-centric. It is good to start with desktop application. Do some drag-and-drop then study the code behind. I am doing the same thing with ASP.NET. I have downloaded tons of starter kits. It all depends on your learning style. For me, I can learn more easily by "learn-by-doing" than by digesting chunk after chunk of set theories. That is why cookbook and headfirst books perfectly work for me.
I believe that the future development model for "Web" applications will more akin to the current model of desktop application development. By which I mean that tomorrow's Web apps won't be HTML/AJAX efforts that are difficult and expensive to maintain, debug and test, they'll instead be developed with compiled languages that target a platform that's already available in the browser. Flash, Silverlight, and (to a lesser degree, it appears) Chrome are the current paragons of this idea.
So maybe it's not such a waste of time to learn those "complex" APIs. My group builds WPF applications and I personally don't find those to be any more complex than the the current crop of HTML/AJAX projects.
From your background in languages, I noticed you only mention PHP and C. Neither language is strictly speaking an object-oriented/OO language. You really should learn a traditional OO language like Java or C#, as the majority of jobs are looking for those skills. BTW, read Yegge's advice on what languages a professional developer should learn, and think for yourself about what you should do.
Assuming that you're interested in enterprise application development, I would have to say that that field is transitioning from traditional web development (present stuff from a database on a web page) to rich internet applications (still present data from a database, but the front end begins to approximate a desktop application). Building a rich internet application will require concepts that desktop UI developers have known for a long time. Therefore, I don't think you have to chose between web development and desktop development.
I agree, you should learn what you want to. Once you have an understanding of Web, then learn some desktop programming to broaden your horizons a bit. You'll never know when you'll need it.
But, also, if you're looking at learning windows desktop development, then you should definitely look at C# and/or VB.NET. The .NET Framework is by far the easiest way to develop desktop app for Windows; much easy than C++ from what I understand (I actually didn't spend much time on C++ myself).
#Rich Bradshaw,
I think you can get answer on your question by looking at any job seeking site.
what should I learn?
Whatever you like and can bring you enough money.
Thats a very good question.
I know nowadays that most app development that im aware of is web apps.
But with languages such as flex , i wouldnt be suprised if the desktop apps came back again.
To be well versed you should do both. Skills in one area may or may not translate into the other very well. The lack of state for example trips up lots of desktop developers when they start building web apps. Of course, your experience may vary
A professional .NET programmer should handle both webform and winform.
Even you start from webform, but finally, you will have chance on touch winform.
Just like a topic "VB vs C#", you will not see a .net expert talk about that, because finally, you should know both of them.
There will be cases where things beyond the web can be used:
Scripting languages/console application - build scripts come to mind here for an example but also writing batch or command files to do simple tasks like handle deployment or to do some other simple task that is likely better done from within a black box rather than manually doing something over and over again.
Windows services(WCF) - These are also possibly useful for monitoring things and sending off those, "Server is down!" messages for someone to go and find out what went wrong.
There is also something to be said for middleware and back-end development where one would write web services or handle querying a database or inserting data into a DB that may not be the same of front-end web UI work, just to give a couple of other examples of software development work out there aside from the embedded systems and mobile stuff that is also non-web and non-desktop development in a sense.