Re: Draft Statement of Direction

[Alejandro Imass <..hidden..>]

Sounds good. Just a few thoughts that we have discussed in the P2EE and
SOLVE ERP projects:

On Mon, 2006-09-25 at 17:51 -0700, Chris Travers wrote:
> Goal 1:  LedgerSMB as Business Infrastructure
> In order to meet changing needs of a diverse market it is important
> that as LedgerSMB grows, that it becomes an easily extensible (and
> even in some cases invisible) part of the data infrastructure of a
> business.  In essence, it must eventually be possible to separate the
> web user interface from the software as a whole.  Important
> requirements we should strive towars are:
>     1)  Separation of mechanism from interface

In fact, IMHO the UI should be split in two layers. One generic UI layer
that defines "what" needs to be done, in XUL, UIML or similar and a
presentation layer that transforms the generic UI into a GUI for the
web, a handheld, text interface, or whatever. The advantage is that the
generic UI can be directly influenced by the business process, so you
can contextualize the "screen" for the given business process that the
user will be executing. This eliminates completely the old paradigm of
all screens being the same or similar, a paradigm that was already
weakened by web apps in general, but for some reason FOSS ERP developers
can't seem to get off their heads. One of the things I liked initially
of SL was the dynamic placement of buttons regarding context, I though
it was quite cool; most "ERPs" still depend on CRUD and BREAD bars at
the top of the screen.

You can download a presentation I gave on this for the SOLVE "ERP"
project. Look especially at slide 14 (in the English version all slides
are commented):

http://erp.solve.net.ve/download.php?list.2


>     2)  Generic, reusable components wherever possible

When we sat down to define P2EE goals we thought that extending,
complementing or creating a new business namespace in CPAN and package
each of the generalized components into CPAN modules. In this sense, we
thought of POE-based application components that could run distributed,
stand-alone or connected to other apps (offering a wide range of
inter-operabillity mechanism offered by POE and POE Components). In the
end, I don't know how practical or feasible this is, but it would
definitively 1) break a lot of paradigms around ERP applications, and 2)
is more consistent with the greatness of Perl, CPAN and it's philosophy
in general.

>     3)  Scriptability from local and remote programs
>     4)  Extensibility of the core logic in forward-compatible ways
>