Hello All,

  I am new to the world of c/c++.  I have a concept application that I am
beginning to work with.  Jan Knepper, suggested that I make use of wxWindows
for this concept.  I am currently reading the tutorials offered via the wx
site and also some books that I picked up at the store.  I know that I will
have issues along the way and will not become the most proficient c/c++
developer for quite some time.

  I am asking for help in designing this application, I don't mind if its a
collaboration thing and available via GNU.  Here is my concept, of course
feel free to add suggestions:

Premise:

A cross platform thick and rich abstract client.  "Essential Collaborator". Web browsers don't give you all the functionality that a company needs to lay out their Line-of-Business applications for remote users.  Remote users don't always have the "ideal" common computer configuration or OS platform to work with.  Finally, Business-to-Business collaboration is difficult to achieve when all you have is just XML alone to do the work.

The idea is to make a "new kind of browser".  This browser supports platforms such as Linux, Mac OS X, and Win2K and multiple user logins/profiles.  It will be unaware of its purpose until the user connects to a specific server to begin their tasks.  The server will announce to the client what is required for authentication, and how the workflow is presented to the user.

Once the initial handshake is complete, the server sends down "datapacks" defining the presentation layer for the user.  The datapacks are then stored locally on the computer.  The versioning of each datapack is verified with the server and updates are sent to the user.  Initially there could be a short delay while retrieving the datapacks for the first time.

Datapacks contain all the information about the GUI, menus, input, colors, graphics and cached data.  I think the format for a datapack can be anything you want, but I am leaning on XML in a hierarchical fashion.  There would be a master datapack listing out the application specifics, Name and About, and a dated (versioning) checklist of datapacks needed for each workflow and any cached data.  Cached data is available for both quicker population of lists and for offline use (If supported by the server).  I don't think that there should be an RDBMs even a simple one required for cached data (MSDE, DB, FoxPro, FileMaker).

There is a basic interface presented to the user when initially launched. This interface allows for the user to select the server and port they will connect to, the user credentials to use, and to update the engine for the client. Communications with the server is via sockets and should have support for SSL.

The engine will have support for common controls (grids, textboxes, labels, sizer, etc.), reporting solutions ( I am leaning toward Crystal Decisions), POP3, IMAP, NNTP, Calendaring and Scheduling, Address Book, and Chat.  These features will be invoked by the application as needed for workflow.  PIM (Scheduling and Contacts) information can be made available for sharing amongst all servers the user connects to, or kept private.

Other support the engine will provide is local validation.  This type of validation can be length of text must be 6-16, or numbers only.  While the requirements are specified by the server hosting the application, the client engine will support and enforce them.  There should also be support for custom help provided by the server.

Each workflow should be on its own thread, and may be multi-threaded in its own right.  Each workflow should also then be communicating with the server via its own socket.  The client engine may have multiple connections to different servers, or launched independently for each server connection. The workspace of each server must not bleed into other workspaces, unless a shared thread is allowed via the user ( I can only think of a chat session with three or more people for this instance).

If a server were to go offline or become unavailable while during a session and it does not support offline activity, the current transactions are logged locally and attempted when the server becomes available.  The client can attempt to re-establish communications while the user has the client open.  Connection credentials should not be stored or cached at anytime, and the server can specify a remote and local connection timeout, in which case the user is notified and the session is closed gracefully.

Well there it is, the initial draft of user requirements.  I have done most of this in Visual Basic 6.0 and VB.Net using both sockets and webservices but to the depth as described.  This only helps out with pc users on Windows 98 and better, I want to reach more users (MAC and Linux).

I haven't played with the use of skins or other types GUI implementation, but I think that version 2 should support that.

If there are other people interested in helping me out, I would appreciate it.  I am not afraid to learn, I just know that this is a tall order for a deficient developer such as I am.

Thanks for your time.