On 1/21/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> > Ok, to clarify-- allowing third party add-ons, providing some
> > directional support, etc. happens today. However, these are somewhat
> > limited in scope by the factors described above. I would expect this
>
> And then break compatibi
Chris Travers wrote:
> We have something to gain.
>
> If we rewrite the entire application at once, I am quite afraid it
> will never be completed simply because it is such a big task.
> Rewriting in Perl gives us the ability to have a useful application
> while we are working on it.
I am not rea
We have something to gain.
If we rewrite the entire application at once, I am quite afraid it
will never be completed simply because it is such a big task.
Rewriting in Perl gives us the ability to have a useful application
while we are working on it. I am sure after 2.0, there may be some
cause
Josh Berkus wrote:
> Chris,
>
>> The core application is probably going to remain in Perl for the
>> foreseable future and probably far longer. However, we are working on
>> adding hooks so that additional functionality could be added in other
>> languages. Rewriting the entire application in Py
Just a few thoughts regarding the possibility of add-ons. THese are
just my opinions and no guarantee that we will go this way, and I
reserve the right to change my mind after discussions wiht the
community and other core members
I would really like to see four stable areas for integration:
On Sun, Jan 21, 2007 at 02:41:58PM -0800, Josh Berkus wrote:
> Seneca,
>
> > There is a GL table, it's just that hardly anything uses it, prefering
> > to add up the other tables and storing its values in the acc_trans
> > table. One of my test instances has an entry in it from when I told the
>
Seneca,
> There is a GL table, it's just that hardly anything uses it, prefering
> to add up the other tables and storing its values in the acc_trans
> table. One of my test instances has an entry in it from when I told the
> system that it was the year end.
Right. In a standard accounting data
On Sun, Jan 21, 2007 at 02:01:25PM -0800, Josh Berkus wrote:
> In the realm of general structure, I'm uncomfortable with the fact that SMB
> does not have a GL *table*. While there's nothing innaccurate with doing the
> P&L on the fly by adding up AR and AP, it's both inefficient and does not
>
Chris,
> The core application is probably going to remain in Perl for the
> foreseable future and probably far longer. However, we are working on
> adding hooks so that additional functionality could be added in other
> languages. Rewriting the entire application in Python seems both
> unnecessa
Ed W wrote:
> Chris Travers wrote:
>> Well, here is my sense (not that I am not sure there is a 100% firm
>> concensus).
>>
>> The core application is probably going to remain in Perl for the
>> foreseable future and probably far longer. However, we are working on
>> adding hooks so that addition
Chris Travers wrote:
> Well, here is my sense (not that I am not sure there is a 100% firm
> concensus).
>
> The core application is probably going to remain in Perl for the
> foreseable future and probably far longer. However, we are working on
> adding hooks so that additional functionality cou
11 matches
Mail list logo
