Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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?



>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 09/02/07 6:23 PM >>>

I was having a discussion with Maxim about the idea we discussed briefly on
a recent Higgins call about collaborating on changes and enhancements to the
C++ GTK-based i-card selector so that it could work with either a local
daemon agent service or a remote hosted agent service.

Maxim said to me that the C++ i-card selector doesn't use WSDL/SOAP services
in the i-card selector, it uses direct calls to ISS. Therefore we would need
to make a lot of changes to use it with our RPPS service.

To which I said:

As I discussed briefly with Andy on a recent higgins call, the idea would be
to work together to arrive at a reusable i-card selector that could be used
with either a remote SOAP service or with a local service. My understanding
is that Novell was already planning at some point to (a) split their single
(H2) process into two pieces, namely: an i-card selector and a backend
(RPPS-like) process. Novell would like their i-card selector to be able to
(optionally) use a _remote_ process and (b) Novell is willing to work
together with others to collaboratively make changes to BOTH the C++ i-card
selector so that it can use either a local daemon process or a remote
process AND to work together to make any changes necessary to the RPPS
service, WSDL, etc. so that the completed i-card selector could work with
EITHER the H1 "RPPS" web service "agent service" or a local C++ RPPS-like
C++ "agent service".

Over time the plan is for all of the Higgins i-card selector components to
converge as to functionality and basic interface design (with
platform-specific differences, of course). It would seem to me that
collaborating so that the H1 deployment config (i.e. the same RPPS "agent
service") could use EITHER the current Firefox HBX (with its embedded i-card
selector) or a new IE-based extension that would launch the C++ i-card

Does all this make sense to you?


Back to the top