Would this project be of interest to anyone?

Clark...you out there anywhere? How does/would this tie into what you are
working on? Or is it an alternative? From checking out James' web site
and from talking with you, they sound like they would complement each
other, but am not sure...

On Tue, 13 Apr 1999, James Thompson wrote:

I've been working on a new project using Postgresql and wanted a little
public input on it.

The goal is a complete office automation package using free software. I
think that if you wanted to use the buzzword of the day you could call it
an ERP package but I'm not 100% sure. You can get more info at

www.math.ksu.edu/~jamest/obe

Would anyone find this kind of a system useful or am I busy recreating
something freely available on the net and thus wasting my time. I'm
interested in any feedback people may have. Thanks!

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

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

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

Regards
Wim Ceulemans - wim.ceulemans@nice.be
Nice Software Solutions - http://www.nice.be
Eglegemweg 3, 2811 Hombeek - Belgium
Tel +32(0)15 412953 - Fax +32(0)15 412954

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?

IMHO, Java is still too slow to use in a full application :( And is still
a relatively moving target (ie. FreeBSD doesn't support Java 2 yet, as is
the case for a bunch of OSs)

Regards
Wim Ceulemans - wim.ceulemans@nice.be
Nice Software Solutions - http://www.nice.be
Eglegemweg 3, 2811 Hombeek - Belgium
Tel +32(0)15 412953 - Fax +32(0)15 412954

I've been working on a new project using Postgresql and wanted a little
public input on it.

The goal is a complete office automation package using free software. I
think that if you wanted to use the buzzword of the day you could call it
an ERP package but I'm not 100% sure. You can get more info at

www.math.ksu.edu/~jamest/obe

Would anyone find this kind of a system useful or am I busy recreating
something freely available on the net and thus wasting my time. I'm
interested in any feedback people may have. Thanks!

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

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Although still very new it is worth to keep a look out for the Cygnus GCJ
compiler. This is a java frontend to EGCS. Still no AWT, SWING and some other
stuff but the first release is out and patches are already being submitted.

Regaards

Lincoln Spiteri

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
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

James Thompson wrote:

I've been working on a new project using Postgresql and wanted a little
public input on it.

<OBE project>

You may want to take a look at Zope (www.zope.org) It's a Python based,
GPLed web/object infrastructure thing. Think of it as a cross between
PHP/ColdFusion and a persistent CGI/ASP application server. It plays
well with Postgresql in my hands (so far) and has an active community
(and company) behind it (Digital Creations: www.digicool.com).

As to using PostgreSQL in a general office automation environment, the
biggest snag I think you'll hit is the 8K limit on tuples, and the
insufficiency of large objects (lo) that's seen so many postings to the
lists lately. Although, apparently, the win32 ODBC driver handles lo's
automatically reasonably well (I remember someone mentioning it being
cool to drag-n-drop big old Word docs and animations into their
PostgreSQL db via MS-Access) Perhaps for the limited case (not millions
of records above 8k, just a few), the existing implementation is
sufficent.

Ross (parenthetically speaking this morning, for some reason)
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005