• Julie M. Holton (77/77) Sep 24 2003 Hello All,

"Julie M. Holton" <mommyof5 sbcglobal.net> writes:

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.