| |
Now don't get me wrong. I'm not got to be authoritarian about this.
This document details the way forward as I see it. Everything is
negotiable.
The Product Overview
There are numerous aspects to this product, but a proposed summary
is listed below. A more detailed description will follow (once
I have typed it out)
- The core
would consist of a database, a server program for serving applications
and data as well as scheduling and running jobs (program scripts).
There would be at least one client capable of presenting the user
interface as served from the server. This portion will be totally open
source and free of charge.
- A developer interface and IDE would run at the client. This
will also be free and open source.
- A product registration module will probably not be open
source to
enable the development team to properly track the number of installations.
People are funny creatures and generally will only complain about
something once it no longer works. Registration will be free of charge,
but will be required to operate. I would like to know, that if there
are 500 users out there, why have only 10 upgraded to the new version
etc. This can only be achieved by registration.
- Application Modules. A module would consist of a related
set of
screens, scripts and reports. This division into modules would be for
the sake of organisation for the application developer but would sit in
the pool of scripts available to all at run time (subject, of course,
to access control).
- Plugin script language extensions - The open source-ness
(there's
one for Oxford) of these extensions would be at the discretion of the
developer.
The core product will be created and administered in this Sourceforge
project. The Main application development, that is, the ERP/CRM
application designed to run within the core will be administered in
another project.
The Target Market
This is a difficult question to answer. The core product, I see, as a
fully scalable replacement for MS Access and the SAP development environment. Granted, some serious design
wizardry will be needed to achieve this from the user perspective, but
as a developer, it will be far more powerful than MS Access and better controlled for
applications that, as we know, grow out of control. It will be far simpler and create much nicer screens than SAP. I certainly see the
future as having some user tools that allow the users to easily create
applications for their own use. I would also like to see some
application import tools being developed to facilitate the world-wide C-Flow explosion.
On the other hand, I see the full application as a direct opposition
product to SAP, BAAN, JD Edwards, Compiere and TinyERP. That's before
we even start attacking the various accounting packages.
Once the core is complete, the next team (or the same one) can start on
the application scripts.
What needs to be done?
Prior to releasing the source:
- Strip out the existing application stuff leaving the
application shell
The new C-Flow
- Some open source
projects that I have used so far and some that I would like to
integrate into this project are listed below. I have chosen these
projects for no other
reason than the fact that I know them - I am completely open to
suggestions.
- TurboCASH
- the accounting functionality in C-Flow is
weak. TurboCASH has an accounting core which I believe can be used to
great advantage. Make no mistake - This alone is beyond my capability
and is no small task. If it can be done then it will be great.
- To enable the handling of an on board CVS for storage and
management of application projects, I propose that FreeVCS by Thomas
Hensle (Now called .....) be incorporated. This project uses
a similar infrastructure to C-Flow and with a little adaptation will
slot neatly into C-Flow. Have a look at the Delphi IDE version. It is
really neat.
- The latest thing in data transport seems to be xmlrpc. I
have downloaded objects that I found at http://sourceforge.net/projects/delphixml-rpc/
that seem to work well. My only hesitation is the size of the
transported xml relative to the raw data. My feeling here is that we
set about developing a set of functions that we need, then build an rpc
wrapper plus an xmlrpc wrapper etc. That would keep the options open.
- Delphi Web
Script, I think, is absolute magic. I would like to rebuild
based on version 2. It is even bigger and better that version
1 and allows the use of functions and procedures. This will require a
futher set of function wrappers to be developed for incorporation into
the DWS framework.
- DSN is a set of components by Kazuhiro Sasaki that allows
run time design of forms and components. A good starting point for the
screen designer. I downloaded from http://www.geocities.com/ResearchTriangle/Thinktank/5653/
many moons ago.
- I currently use SynEdit for the IDE editor. http://synedit.sourceforge.net
- There will be more......
- The first step will be ......
- ...
Once the Engine is built
- Design the Application....
- Get Sourceforge to add a new development environment to their options
- move this to a new project in Sourceforge
- Start an entirely new way of building business applications
- .....
Home
|
|
