Chris
I think you were going to look at a duedate problem in one (some?) of the
AP forms of 1.2.
Were you able to investigate that?
Just trying to keep it on the burner somewhere--by its nature it is not a
critical bug, obviously.
If you don't think you will get to it any time soon, I may tak
I understand the excitement about moving to 2.0--I share it. I don't
expect ever to switch to 1.3 in production, if 2.0 gets going in the next
18 months or so.
I'm even looking forward to contributing to it, as much as I don't like
PERL.:)
After I sent my message, I thought about it again. I
On Thu, Mar 11, 2010 at 9:27 PM, Ian Goodacre wrote:
> On Thu, 2010-03-11 at 12:49 -0800, Chris Travers wrote:
>> If it's ok with you...
>
> It certainly is. And thanks for the prompt attention.
>
I have committed my fixes here. Feel free to review and suggest changes.
Best Wishes,
Chris Travers
Ok. Seems like a consensus has emerged. Shelve this until we get to
the release candidate series.
Best Wishes,
Chris Travers
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compil
Michael Richardson wrote:
>
>> "Chris" == Chris Travers writes:
> Chris> I think we should look at branching LedgerSMB 1.3 off this
> Chris> next week since the basic ideas of 2.0 are starting to take
> Chris> shape. What do folks think?
>
> I think that it's a recipe for su
On Sun, 14 Mar 2010, Armaghan Saqib wrote:
> This was exactly what I was thinking but I thought I might be missing
> something why this is being done.
Not all of the same reasons, but ditto.
My initial thought was "Is the plan for 2.0 sufficiently mapped out in
developer documentation yet?" We
On Sun, Mar 14, 2010 at 8:22 AM, Michael Richardson wrote:
>
>> "Chris" == Chris Travers writes:
> Chris> I think we should look at branching LedgerSMB 1.3 off this
> Chris> next week since the basic ideas of 2.0 are starting to take
> Chris> shape. What do folks think?
>
> I think
On Sat, Mar 13, 2010 at 7:18 PM, Adam Thompson wrote:
> Chris Travers wrote:
>> On Sat, Mar 13, 2010 at 5:21 PM, Luke wrote:
>>> I am assuming SSL. Correct me if I am wrong, but my recollection is that
>>> the query string (I.E. get) is in the clear with SSL, whereas post data is
>>> not.
>>> Do
> "Chris" == Chris Travers writes:
Chris> I think we should look at branching LedgerSMB 1.3 off this
Chris> next week since the basic ideas of 2.0 are starting to take
Chris> shape. What do folks think?
I think that it's a recipe for suicide of the project.
You can't start 2.0
Chris Travers wrote:
> On Sat, Mar 13, 2010 at 5:21 PM, Luke wrote:
>> I am assuming SSL. Correct me if I am wrong, but my recollection is that
>> the query string (I.E. get) is in the clear with SSL, whereas post data is
>> not.
>> Do I have a fundimental misunderstanding or massive brain fart h
On Sat, Mar 13, 2010 at 5:21 PM, Luke wrote:
> I am assuming SSL. Correct me if I am wrong, but my recollection is that
> the query string (I.E. get) is in the clear with SSL, whereas post data is
> not.
> Do I have a fundimental misunderstanding or massive brain fart here?
The SSL negotiation
On Sat, 13 Mar 2010, Chris Travers wrote:
> On Sat, Mar 13, 2010 at 1:09 PM, Luke wrote:
>> On Sat, 13 Mar 2010, Chris Travers wrote:
>>
>>> On Sat, Mar 13, 2010 at 12:12 PM, Luke
>>> wrote:
>>>
>>> Furthermore, if we agree that data shouldn't be saved to the db on a
>>> GET request, then the X
On Sat, Mar 13, 2010 at 1:09 PM, Luke wrote:
> On Sat, 13 Mar 2010, Chris Travers wrote:
>
>> On Sat, Mar 13, 2010 at 12:12 PM, Luke wrote:
>>
>> Furthermore, if we agree that data shouldn't be saved to the db on a
>> GET request, then the XSRF benefits are the same.
>
> I guess I was thinking mo
On Sat, 13 Mar 2010, Chris Travers wrote:
> On Sat, Mar 13, 2010 at 12:12 PM, Luke wrote:
>> Wouldn't it be somewhat more secure, not to use get at all?
>> Or, at least, very minimally?
>>
>> We won't be sending passwords that way any more, but still...
>
> Well, it doesn't entirely prevent XSRF
On Sat, Mar 13, 2010 at 12:12 PM, Luke wrote:
> Wouldn't it be somewhat more secure, not to use get at all?
> Or, at least, very minimally?
>
> We won't be sending passwords that way any more, but still...
>
Well, it doesn't entirely prevent XSRF attacks, so the benefit would
be very minimal.
Fu
On Sat, Mar 13, 2010 at 12:00 PM, John Locke wrote:
> I do think being able to accommodate XML is a necessity, especially for
> integrating with all of the other systems that use that as a medium.
This gets into the representation stuff I was talking about before.
Namely that some of the formats
On Sat, 13 Mar 2010, John Locke wrote:
> I do think being able to accommodate XML is a necessity, especially for
> integrating with all of the other systems that use that as a medium.
I started to write my own back on SL, because of the need to handle EDI
transactions. Fortunately, that project
Wouldn't it be somewhat more secure, not to use get at all?
Or, at least, very minimally?
We won't be sending passwords that way any more, but still...
Luke
On Sat, 13 Mar 2010, Chris Travers wrote:
On Sat, Mar 13, 2010 at 11:32 AM, John Locke wrote:
Just reading back through the architectu
On Sat, Mar 13, 2010 at 11:57 AM, Chris Travers wrote:
>> get_params => '*%',
>> raw_post => '$', # only populated on POST/PUT
>
> Good points. Accepted there.
Just noticed a minor change that needs to be made to the above:
instead of get_params, we should probably call it uri_params since
o
I do think being able to accommodate XML is a necessity, especially for
integrating with all of the other systems that use that as a medium.
However, put me in the JSON camp for actual new application
development--far less wordy, a lot quicker in browser-based application,
and just as easy to pars
On Sat, Mar 13, 2010 at 11:32 AM, John Locke wrote:
> Just reading back through the architecture threads, and I think it all
> mostly sounds great, I like the direction you're going.
>
> One thing comes to mind: I don't see a way of detecting in the Request
> struct the difference between a query
I was thinking yesterday, that it would be nice to have an entire XML
based interface. If most of the system was a backend which handled XML
documents, the frontend could be a web app, a thick client, or any other
sort of thing--the backend would have no reason to care.
All a new module would
Just reading back through the architecture threads, and I think it all
mostly sounds great, I like the direction you're going.
One thing comes to mind: I don't see a way of detecting in the Request
struct the difference between a query argument in the URL vs the body,
e.g. GET vs. POST parameters.
On Sat, 13 Mar 2010, Chris Travers wrote:
> Follow-up question: Should we have a separate .ini file for web
> application configuration?
What non-DB-driven web application configuration parameters exist? I.E.
those which are not handled in the webserver config.
Luke
On Sat, Mar 13, 2010 at 11:20 AM, Luke wrote:
> On Sat, 13 Mar 2010, Chris Travers wrote:
>
>> On Sat, Mar 13, 2010 at 10:46 AM, John Locke wrote:
>>> Ok this might be a dumb noob question, but why use some hexadecimal
>>> notation of the module? Why not just the string module name?
>>
>> I was t
On Sat, Mar 13, 2010 at 11:07 AM, John Locke wrote:
> I'm not a big fan of error codes, and coding modules so that casual
> programmers not familiar with the codebase have to go hunt around to
> find the source of the issue... well, ugh.
The idea of error codes is to solve a different set of prob
On Sat, 13 Mar 2010, Chris Travers wrote:
> On Sat, Mar 13, 2010 at 10:46 AM, John Locke wrote:
>> Ok this might be a dumb noob question, but why use some hexadecimal
>> notation of the module? Why not just the string module name?
>
> I was thinking about having a much more compact error notation
On Sat, Mar 13, 2010 at 11:00 AM, Chris Travers wrote:
> I am thinking of suggesting two global namespaces
>
> In package LedgerSMB
>
> use Class::Struct LedgerSMB::Globals => {
> user => 'LedgerSMB::User',
> session => 'LedgerSMB::Session',
> config => 'L
I'm not a big fan of error codes, and coding modules so that casual
programmers not familiar with the codebase have to go hunt around to
find the source of the issue... well, ugh.
I'd like to be able to see from the exception what module threw it,
where in the code it was, and what triggered it. I
I am thinking of suggesting two global namespaces
In package LedgerSMB
use Class::Struct LedgerSMB::Globals => {
user => 'LedgerSMB::User',
session => 'LedgerSMB::Session',
config => 'LedgerSMB::ConfigFile',
# Config settings, s
On Sat, Mar 13, 2010 at 10:46 AM, John Locke wrote:
> Ok this might be a dumb noob question, but why use some hexadecimal
> notation of the module? Why not just the string module name?
I was thinking about having a much more compact error notation. Maybe
the namespace it is called from would be
Ok this might be a dumb noob question, but why use some hexadecimal
notation of the module? Why not just the string module name?
-- John
Original Message
Subject: [Ledger-smb-devel] Error Handling in 2.0
From: Chris Travers
To: Development discussion for LedgerSMB
Date: Sat 1
Hi all;
I am looking into error handling beyond 1.3 and wondering what people
think. I am tentatively inclined to suggest as follows:
use Class::Struct LedgerSMB::Error => {
type => '$', # one of FATAL, ERROR, WARN, DEBUG, INFO
module => '$', # Hexadecimal notation of module raisin
On Sat, Mar 13, 2010 at 2:17 AM, Luke wrote:
> If this was fixed in versions above 1.2.18, I apologize.
>
> templates
> sales_order.tex
>
> 134,136:
>
>
>
>
>
> "end if" is not, afaik, a proper construct. "end notes" would be the
> proper construct here.
Hmmm Let's get 1.2.21 out the d
If this was fixed in versions above 1.2.18, I apologize.
templates
sales_order.tex
134,136:
"end if" is not, afaik, a proper construct. "end notes" would be the
proper construct here.
Assuming this is correct, the error appears in other templates as well.
r...@pecunia:/usr/share/ledge
35 matches
Mail list logo
