Slashdot Mirror

← Back to Stories (view on slashdot.org)

Web Interfaces for C++ Introspection?

Posted by Cliff on from the tune-ups-while-still-executing dept.

Milo_Mindbender asks: "For a C++ application I'm working on I want to be able to pop up an interface to a class that will display all the 'tunable' parameters of the class and let me inspect/modify them, while the program is running. The catch is that I'm running on a minimal embedded OS with Open GL but no GUI library. Rather than porting a widget set or writing my own, I was thinking about having the application talk to a web browser, and then use the browser to display the GUI, take user input, and finally push the data back to the app. The classes have metadata that describes the public data locations/types so they can be accessed, but not being a web-wizard I'm not sure of the best way of generating the information I need to create the UI. My first thought is to generate HTML and push that to the browser, but it seems like there must be a better way than this, maybe someone has written a library specifically for doing this sort of thing? Any help/suggestions would be appreciated!"

17 of 66 comments (clear)

  1. Why GUI by the+eric+conspiracy · · Score: 3, Insightful

    Any particular reason that it has to be a GUI? Something like an ncurses interface might be a lit easier.

    1. Re:Why GUI by billcopc · · Score: 2, Insightful

      I second this opinion. Remote debugging or "tuning" could be rather easily done from a serial terminal. There's no need for an HTTP protocol and the sloppy hassle of HTML forms; just a quick text console, not unlike those found in games such as Quake.

      get myvar, set myvar xxyy, toggle myvar, listvars etc etc

      Yeah, web interfaces are nice for end-users, but since you just want to debug your own one-off app and it's quite likely you will be the only person doing it, might as well be lazy - I mean efficient - and code the simplest interface possible, as long as it does what you need.

      --
      -Billco, Fnarg.com
  2. This question is odd.... by Manip · · Score: 2, Insightful

    I find this question somewhat odd... The guy clearly knows C++ and is able to develop on an embedded OS which isn't an easy thing to do but yet can't write himself a simple web-server, which a lot of us learnt during our first few years of programming in something nooby like VBA or Java...

    So either he isn't being completely accurate in so much that he might not be as knowledgeable as he claims or just by freak chance managed never to write a web-server in a couple of hours like everyone else...

    1. Re:This question is odd.... by FooAtWFU · · Score: 2, Interesting

      Well, I'm a junior in college and a computer science major, studying things across the spectrum from kernels to compilers to recursive descent parsers to Turing machines and much of the stuff in between. I've had several jobs dealing with web or Intranet applications and embedded development. And I've never written a web server. I've never even considered it. I've written some pretty low-level CGI bits for C/C++ applications (parsing query strings and POSTs) and I've written some TCP/IP network communication bits, and I'm sure I could write a web server if I had to but... why should I ever need to? I've got Apache, I can look at other web servers like Tux, even IIS... and I have well-defined interfaces to these like CGI, and mod_perl, and things like JSPs for Resin. Write a web server "like everybody else?" I sincerely doubt that even one in fifty programmers have written them- and I'll even let you choose the definition of "programmers". Of all the nifty applications you could possibly imagine to write, why would you choose a web server?

      --
      The World Wide Web is dying. Soon, we shall have only the Internet.
    2. Re:This question is odd.... by Rezonant · · Score: 2, Interesting

      I'm studying for a CS masters and a UNIX-based web server is the final project of our "Systems programming in C" course. It's an optional course though. Oh and BTW, fork() and the unix process model sucks as a parallellism primitive. I love Win32 threads and io completion ports :/

    3. Re:This question is odd.... by MarkRose · · Score: 2, Informative

      Unix has threads, too. Recent Linux kernels have particularly fast threading.

      --
      Be relentless!
    4. Re:This question is odd.... by Short+Circuit · · Score: 4, Informative

      Oh and BTW, fork() and the unix process model sucks as a parallellism primitive.

      You're right...you should use pthreads or nptl instead.

      Some advice from someone who makes the same mistake every now and then...When you learn something in class, don't talk about it on Slashdot for at least a month. That'll give you a chance to think before you type.

      In the mean time, dissing UNIX around here is likely to get you modded "Troll."

      --
      tasks(723) drafts(105) languages(484) examples(29106)
    5. Re:This question is odd.... by Omnifarious · · Score: 3, Insightful

      Well, I didn't assume he was asking how to write an http server. I assumed he was looking for introspection facilities like Java's, which C++ doesn't have. I wish it did. typeinfo could be that if any compiler manufacturer implemented a rich enough set of extensions to it.

      It would be nice to get, at runtime, a list of pointers to functions a class supported as well as their names and type signatures. It would also be nice to be able to get a list of members and their types and their offsets from the beginning of the class.

      --
      Need a Python, C++, Unix, Linux develop
    6. Re:This question is odd.... by BigZaphod · · Score: 2, Interesting

      Out of the 20 or so programmers I've known rather well over my life so far, about half have resorting to building their own web server (even in languages like Perl). They've done it for kicks (because, seriously, HTTP 1.0 is *easy*) or for practical reasons (like for the sort of problem you're having). Servers like Apache and IIS are for heavy loads and high reliability - but HTTP itself is a really simple protocol. Writing your own server should not only be reasonably trivial for someone such as yourself (from the sounds of it), but also an eye opener into a whole new way of approaching your problems. You said yourself that you never even considered it. Now consider asking yourself why not?

      --
      Hexy - a strategy game for iPhone/iPod Touch
    7. Re:This question is odd.... by GileadGreene · · Score: 4, Informative
      BTW, threads of any sort suck as a parallelism primitive. A better choice would be CSP-style process networks, as implemented in occam and C++CSP. Erlang implements a similar (but not identical) concurrency model.

      Why would you want to use a CSP-style concurrency model instead of threads? To quote from the occam compiler homepage:

      CSP has a compositional and denotational semantics, which means that it allows modular and incremental development (refinement) even for concurrent components. In turn, this means that we get no surprises when we run processes in parallel (since their points of interaction have to be explicitly handled by all parties to these interactions). This is simply not the case for standard threads-and-locks concurrency, which have no formal denotational semantics and by which we get surprised all the time.

      In layman's terms, you get concurrency that can be built up from easily understood pieces (instead of a monolithically concurrent system with locks scattered throughout the code), and an underlying theory of concurrency that lets you understand and analyze your design and ensure that it is, for example, free of deadlocks (I've personally created complex networks of 1000+ interacting processes in a dynamically evolving topology, with nary a hitch). And did I mentioned that the context-switching performance of most of these systems is amazingly good?

  3. Well, you don't necessarily need a web browser... by FooAtWFU · · Score: 2, Insightful
    Instead of embedding a mini HTTP server into your application so it can talk to an application, you could just write a GUI in your favorite language (Java? C++? Java?) and talk to it with good old-fashioned TCP/IP (or even UDP) network sockets. Probably a lot simpler to define your own stuff than to deal with a big old standard like HTTP and parsing all the browsers which may be mangling your requests.

    If it must be accessible via the web/intranet/browser/etc, set up some of your favorite CGI/PHP/JSP/Python/Ruby and have it talk to the application via TCP/IP and to the browser with HTTP.

    --
    The World Wide Web is dying. Soon, we shall have only the Internet.
  4. Remote XUL by dorkygeek · · Score: 2, Informative

    You may be interested in XUL then. Especially, in remote XUL.

    Also, see Remote XUL Application Development with_Mozilla I and Remote XUL Application Development with Mozilla II.

    You may even be able to create the UI XML files automatically from your interfaces, using a script, or introspection.

    You can then send the data back to your host, using RPCs or a REST-like interface.

    --
    Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
  5. Light minimal XML interface by Zarf · · Score: 2, Interesting

    You might consider a very minimal XML interface on top of a very very very simple HTTP server. Your UI could live on a completely different device on a completely different server... or on the same server in a different application stack. You could run your service on port 8080 or something if you didn't want to run it on 80 to prevent

    You could display your state as a single XML document that is gotten at a single URL. Each setting could be manipulated by posting to a URL specified in the XML document. These sets of documents and post URLs could become a simple CGI set of interfaces you could describe for anything from webservers, application servers, or other web-aware C++ programs to hook into.

    --
    [signature]
  6. GLUI by tfinniga · · Score: 3, Interesting

    Have you looked at GLUI?

    --
    Powered by Web3.5 RC 2
  7. What about ICE or CORBA? by motus · · Score: 3, Insightful
    I think the challenge here is not how to represent the data visually (i.e. web/GUI), but how to control a C++ object from the remote application. For that puropse, I would suggest CORBA. You can define all controllable classes in CORBA IDL, compile it into C++ code and integrate with your existing application with minimum efforts. CORBA client should not necessarily written in C++ - it can be Java or Python, for example. I have very good experience with omniORB (http://omniorb.sourceforge.net/). It supports both C++ and Python, and I use a bunch of Python scripts as a test harness for my C++ CORBA services. Besides omniORB, there are lots other decent implementations of CORBA in many programming languages (http://www.omg.org/technology/corba/corbadownload s.htm).

    PS. Good alternative to CORBA is ICE (http://www.zeroc.com/ice.html), which is basically the same thing as CORBA, and founded by one of the CORBA gurus. ICE has much better C++ mapping, and lots of other nice features.

    Hope this helps!

  8. Use Qt by e8johan · · Score: 2, Interesting

    Use Qt and declare your tunable parameters as properties. Writing a minimal server using Qt is trivial.

  9. Slight variation on the 'generate HTML' theme by ArwynH · · Score: 2, Informative

    How about minimal server-side XML + Client side XSLT?

    Requirements:

    1. minimal http server (There is bound to be BSD licensed code for this somewhere on the net)
    2. Code to generate simple (possibly flat?) XML file. You don't need a library for this, you could just pretend it's a text file if the XML is simple enough.
    3. XSLT and CSS stylesheets

    Now all you have to do is serve the XML and stylesheet, attach the stylesheet to the XML file and watch any XSLT-aware browser do the heavy work of transforming that simple XML into beautiful XHTML (or HTML) for you.

    Benefits:

    1. server side code is farely minimal (just a mini-http server and xml generation code) and some of that (mini-http server) can probably be re-used from elsewhere.
    2. Full content/UI seperation. Client doesn't like the UI? just change the XSLT/CSS till he does, no need to re-write code. You could also write small client program that uses the XML data if client doesn't like using a browser, again no need to re-write code.
    3. Less time-consuming than writing a full-scale UI

    Problems:

    1. Requires XSLT-aware browser. Mozilla and Opera support it no probs. IE supports it aswell, but has a few glitches (suprise!).

    Why re-invent the wheel writing C++ UIs and stuff when there is plenty of simpler ways out there.