Re: Looking beyond 1.3: Kernalization and requirements proposals.

[Chris Travers <..hidden..>]

On Sat, Mar 6, 2010 at 10:56 AM, Luke <..hidden..> wrote:

>
> For what it's worth, I, big surprise, support this.
>
> I am more of a user than a developer right now, but this would make the
> development door a bit easier to pass through, I should think.
>
> Can the codebase be moved to PHP while you're at it?;-)  (A guy can dream,
> even if unrealistically)

Well, the main Perl framework stuff I am looking at would be easy
enough to port to PHP if someone wanted to (main application is that
it would allow for addons to be written in PHP).

However, quite frankly, the same can be said of Python, Ruby, C, TCL,
and any other language with database access.  That's one of the nice
things about where we are headed:  the overhead to integrate with the
application is fairly low and will become lower in 2.0.

> I'm all for fewer CPAN modules being required.  What is the difference
> between "basic" and "full" customer/vendor management?

Basic meaning "track customer/vendor accounts, locations, contact
info, credit limits, discount rates, etc."
>
> Am I correct that without an inventory framework, it would not be possible
> to provide invoice functionality as we now think of it?

Correct.  AR/AP transactions would be what would be standard out of
the box under this proposal.

With inventory, you would also get invoices against goods/services, etc.

> Some sort of simplified service invoice would have to be included,
> overrideable by a full invoice with the inventory package.

AR/AP transaction screens would be comparable to what I am thinking
though with usability improvements.

I am also thinking it may be helpful to look at two different ways of
distributing the software.

One would be a "core" release which would be minimalist and clearly
labelled as such.  The other would be a "bundle" which would include
commonly used addons.

Best Wishes,
Chris Travers