Long - More info on project Was Re: [GENERAL] Would this project be of interest to anyone? - Mailing list pgsql-general

On Wed, 14 Apr 1999, Wim Ceulemans wrote:

> Why not use Java in stead of SWIG - TCL/TK - PHP? Or is java not free in
> your opinion?
>

No, I really don't have a problem with the freeness(?) of java.  I like my
stuff being under the GPL, but I'm not a fanatic about it.  Whatever it
takes to get the job done without restricting the programmers or users.
I'll give info on why I didn't choose java for obelib at the bottom.  But
first....

I'm know what I want the system to do.  I'm just bad at explaining it :-)

Here's a little more info.

I envision a single library of business objects.  It would also be the
place to add new features that enhance the entire project (I thinking
about CORBA now, but don't know enough about it yet)  the current copy of
obelib contains customers, lineitems, packets (working name for the
Quote/Sales object), connections (persistant storage), business info, and
configuration info.  This library will serve as the backend to whatever
interface you want to use.  It could be a TLC/TK GUI like the working
prototype packect maintenance screen, a C program like the one that
generated the postscript output for the Quote/Sales packet printout, it
could be a java applet running under a web browser.

This library is currently available to any language that can interface
with C functoins (IIRC java can). By wrapping that library with SWIG its
functions become available to whatever scripting languages supports, of
which java is one.  The goal is to allow a greater number of choices for
the programmer.  People can use what their confortable with and will
hopefully want their work included in the project.  There is no way I can
create this system by myself and include all the features different
business segments would require (manufactures, wholesalers, medical,
legal, educational, etc. etc.) so I want it to be easy for others to
contribute.

What I'd really like to end up with is a set of core components that have
a specific set of requirements.  (What those components are and what their
requirements will be is open to debate, I'd love feedback on what people
need.)  And additional components that work well together regardless of
the language used to create them each listing its individual requirements
(perl, C, etc., etc.) so that each person can make up their minds what to
use.

In fact, there is no requirement to use obelib at all.  I'm 100% positive
that things will come up that will be kludgy if using obelib.  People are
free to provide code that access the data storage system directly.  These
components would have a few drawbacks

  when obelib supports more backends, the programs wouldn't get that
  support transparently.

  business logic in obelib would need recreated in those components
  increasing the possibility of bugs.

  changes in the storage structures would break the programs.

Having said that, I see no reasons why these programs couldn't be included
with a little disclaimer stating that the program is compatible but with
issues.  Once the code is available, it can be reviewed and would provide
insight on ways to make obelib better.  Hopefully the program could then
use the improved obelib.

Now, as for why the core isn't written in java. (Feel free to tell me
where I'm wrong ;-)

  I felt that C is well supported by the free software community so
  alot of programmers feel comfortable with it.

  Almost everything interfaces with C, I didn't think java was as
  easily intergated with other projects.

  A JVM is not available for every possible machine that a free C
  compiler will run on.  I know this is improving.

  Java is a quickly moving target as far as it's API is concerned.  When
  I lasted programmed in java there were three different GUI methods
  available


Java components are certainly welcome, I just didn't think it fit the bill
for the core library.

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson    138 Cardwell Hall  Manhattan, Ks   66506    785-532-0561
Kansas State University                          Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<