|[higgins-dev] Re: Collaborating C++ i-card selector|
This sounds like a good direction. Because the UI is very platform/framework specific, whereas the core code is platform agnostic, separating the two is very desirable from an architectural perspective. This is how the H2 was originally implemented when we had to get a "quick-and-dirty" version ready for Brainshare -- we reused the C# UI from the CASA project and extended it to meet our needs. Because we want to provide a thin client, we are very interested in a client/server interface between the UI and the core selector service. The assertions you enumerate below (based on our conversation) are correct. However, I see three possible deployment scenarios for the H2: a) A single, "monolithic" selector where the UI and RPPS run as the same process (see my reasoning below); b) a thin client process that talks to a local RPPS service; and c) a thin client that talks to a remote RPPS service.
We have been focused for the past month on getting the C++ selector to run under OS X. Since the core code is cross-platform, most of the effort has been spent on the UI. At first, the hope was to simply port the GTK-based UI to the Mac, but it became obvious that the various attempts to port GTK to OS X have either been abandoned or are missing a great deal of functionality. For this reason, we decided that it wouldn't be possible to use GTK on the Mac. Because Cocoa and Objective-C++ are very unique to the Mac, we also discussed writing the Mac UI in Java with either a JNI or RPC to the ISS. There is a caveat to this approach, however.
In the Mac world, it is highly desirable to package and deliver software in a format that allows for a "manual" install. Basically, this means that installing software is as simple as dragging an application from a mounted disk image (or cd/dvd) to a destination folder. Likewise, to upgrade an application, the new version is simply copied over the old version. To subsequently remove the app, the user drags its icon to the trash. If the application requires a service to be installed (i.e., to listen for soap requests), the installation and maintenance (upgrades, etc.) of the application becomes significantly more complex and also requires admin privileges. Given this, we decided to go ahead with a Cocoa/Objective-C++ UI and a "monolithic" selector service for the Mac. If we can come up with a slick install that meets the needs of Mac users, I'm not opposed to mothballing the monolithic selector, however.
How should we proceed?
Back to the top