Derek Neighbors (derek) asked Jeff Bailey (jbailey)
think you can .debianize the latest dcl
release?
He was still planning, long-term, to convert DCL
to a GNU Enterprise tool
.
Alternatively, he suggested Jeff might like to help
me understand packaging enough to take
it over so you arent wasting time maintaining something you are not
directly involved with
. Jeff said that if
You can't upload it, so there's no point in
you maintaining it. The ideal is that you should find a DD that cares
about DCL.
Derek said he was keen to become a Debian developer,
and felt that maintaining DCL would be a good place to start.
Jeff said that there were three steps to becoming a Debian developer -
1) Get your GPG key signed by a DD - 2) Read
the packaging and policy manuals. - 3) Find a sponsor. I can do #3 if
you have #1 and #2 done.
. He noted that
The DCL packaging is annoying because it's a
PHP app. What's the time frame for turning it into a real app
based on the GNUe Tools?
Charles Rouzer (Mr_You) asked anyone have
any thoughts on how workflow is expected to be done in
gnuenterprise?
- Documents can
TimeOut, be Rejected, Acknowledged, Auto Routed
and so on.
D Smith (dsmith) noted At the last
place I worked
he was trying to get
time sheets automated
- One big big
issue is that the customer has to sign the sheet. We were thinking about
ways to let the customer approve the sheet with a web based form.
But then there are security issues. Cutsomers looking at other customers
projects, etc. With a piece of paper, you can wave it under his nose and
he will sign it, but try an get them to go to a web page with tricky
authentication.
Charles said I'd like
to get something started in GNUe so that my app is somewhat GNUe
compatible. right now, I'm thinking the workflow engine would run in cron
to automate/timeout/etc.
One solution for this scenario
could be the user receives an email with a url
to the document he must "sign".. no authentication really needed
as of course the url to that document would
contain a "random key" to make it a little more secure.
D Smith felt that The whole "customer calls;
trouble ticket generated; worker logs time; time approved; bill generated"
sequence ought to be fairly common. Any service industry.
.
Derek Neighbors (derek) said he had spoken
ad nausem about
workflow previously - unlike others, he did not
see it as just another part of appserver
.
Charles said he would like any work he was doing for himself to form the
basis of (or, at least, be compatible with) whatever GNUe was doing on
workflow - I guess I'll submit some proposals
and get ya'lls input then
. Derek said
the key pieces i see as being necessary for
success - 1. highly flexible (non programmer) way to define flow - 2.
multiple transport mechanism - for part 1 i think of xml based rule
flow
, similar to the existing GNUe Forms Definitions (*.gfd) and
GNUe Schema Definitions (*.gsd). for part 2
i mean just like we are UI and Database agnostic, so too should we be
'notification' agnostic - i.e. we should support web, email, jabber etc
etc etc. i had diagrams and docs somewhere - but its been a while
.
He noted that GNUe Common already has rpc
communication necessary for 'notifications'
and
has strong xml parsing engines
.
D Smith said he was thinking email, pdas,
text messaging phones, and pagers
as possible notification
methods. Derek said he was thinking jabber
would be interesting and have jabber embedded into GNU Enterprise framework
(optionally) - so when you login to a GNU Enterprise application you have a
little 'message' status bar
D Smith noted there were
sms and smtp trasports for jabber.
Intresting.
Derek said i suspect we
will support all of those things - i.e. even within a company someone may
like IM more than e-Mail - or prefer both. i know most 'approval' things i
would want email - as IM or a page is reserved for 'important'
things
.
Dmitry Sorokin (ra3vat) said there were other people
using my forms under windows - so it is not just
my tests
, but there are no completed
gnue-based ERP applications currently
. Christian Selig (lupo)
pointed out you forgot project papo -
which is complete, but it is available in spanish only :( - it was written
only with argentina in mind - but i heard something about papo people
targeting whole south america in the long run
. GNUe allowed you
to develop data-driven applications quite
rapidly
. Any programming needed to be done in python, but
Christian had found this quite easy to learn -
it's more like javascript "done right"
.
In any case, usually, 98% of a gnue based
application is written in XML - you don't "program" an app, you describe
it
.
For people looking for an existing free software ERP,
nola is a web-based free ERP from noguska.
development has stopped and some other group took it over.
Where an application was mainly about displaying
and maintaining data
without a lot of
computations
, writing it in GNUe could be very quick - it would
probably take longer to set the database up than to write the form definitions
for GNUe Forms!
Derek Neighbors (revDeke) admitted he had been dubious about Navigator at first
and really thought we needed extendable menu structures
in the forms API
but, having seen how other ERP packages worked,
i think navigator is more the way to go
.
Christian Selig (lupo) said without a basic RBAC
(Role Based Access Control - the ability to set which users can see/use which menu
options) it is not usable for me
.
Jason Cater (jcater) conceeded that the original navigator
was(is) clunky - navigator certainly isn't in its final form
. Derek
suggested maybe if you could dock it to the main form
or have the forms open w/in navigator in an MDI type function - i think it will be
HIGHLY usable - as of now its still usable
. Jason said
as with all things I see this as pluggable - I want an
MDI-like interface that you describe (perhaps that will even become the default ..
.I dunno) but the beauty of the .gpd -like definition
was that people
could write their own Navigator client or Navigator plug-in to present the contents
of the GNUe Process Definition (*.gpd) file any way they wanted to.
Christian asked what do you think about "tabbed
browsing" for forms within navigator?
Derek preferred trees, as he felt
they were more intuitive for business people. Derek noted that both SAP and
Peoplesoft had a menu system where end-users could build their own menu from the
choices available - i.e. its almost like a
'favorites'
. He would try something similar in the GNUe Small
Business application he was developing.
Further to is hoping to slurp
ARIAS
, the free software project based on NOLA,
and compare it to acclite
, GNUe's own
version of the NOLA code tree. with any luck i can
run patches against acclite - hen beg you guys to kill ARIAS cvs and use Acclite
instead - /me garners his evil laughter
. Later, he concluded it would
not be as simple as that - not impossible just will
be time consuming
. Chan Min Wai (dcmwai) said I've
modified arias a lot .... really alot....
but noted that much of this
was related to adding Languages translation
Modification
- ignoring these, I think that the
differenr will be alot more smaller.
Later, as the arias developers gathered on the channel, Derek said that
the main issues for him with respect to co-operation were
item 1 for me is are you willing to assign copyright
to FSF on all future works? item 2 is are you willing to break all NOLA
compatiablity and dependencies
Josh Flechtner (jafgon) was fine on the
first point, but more worried about the second - i
am willing to break for a better solution but not just for the sake of
breaking
. Chan felt that breakage was not an issue, as long as there
was an upgrade path. Derek said GNUe could help with this. He felt that
incompatible changes were inevitable as their
inventory, invoicing etc is WAY too print shop specific
, reflecting
the needs of Nogasaku, the original authors of NOLA, who wrote it as a GPL
(free software) accounting package to sit alongside their proprietary print shop
management software - however, the HR and Base
Accounting (ledgers) we might be able to not gut too severely
.
Derek emphasised that GNUe had a very broad vision - it was intended
eventually to be a free replacement for full ERP systems like SAP and Peoplesoft,
rather than a Quickbooks or Peachtree replacement. Having said that, the
GNUe Small Business sub-project had a less ambitious focus -
i see gnue-sb as being a 2-tier small/medium
enterprise base package - so you would get basic invoicing that works 80% of
your needs - then a non programmer can modify forms/tables as necessary to meet
the other 20% for the vertical industry you are in
-
we want something quickly - not something perfect -
gnue proper (the official gnue ERP packages) are available for those wishing
to over design a system - gnue-sb belongs to get something out to meet basic
needs
.
Derek said he had gone off the idea of porting
all arias changes back into acclite
- assuming that the changes from
NOLA to acclite had not taken too long, it would probably be easier to do this
the other way around and apply the acclite changes to arias,
then check into gnue-sb cvs or some fresh
cvs
. Jason Cater (jcater) said I think I spent
a saturday night on the restructuring
- both the directory cleanup
and adding postgreSQL support - so it's probably not
a big deal to do it again if need be
. Josh said he would still keep
the sourceforge page for arias up, and would answer any "SOS" support e-mails,
but would focus his main effort on a joint gnue-sb/arias venture. Derek agreed -
i suspect it will take a little time to get
gnue-sb up and usable so ARIAS still is an option until that time (another
reason not to cut it off)
.
They discussed the practical steps involved
in merging the code base - Derek said the priorities were to
get dir structure over
and
get schema converted to gnue schema format
.
After that, the priorities, in whatever order people felt was urgent, were
to fold in the existing Product and Contact support from GNUe Small Business,
and adding the accounting functionality that Jason had
requested.
Josh and Chan discussed whether there were any urgent fixes they needed to
apply to the arias code before the merge.