Home/ Questions/Q 756631
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T15:16:01+00:00

For a current project, we’re designing a client desktop application that parses text files

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0