"L.C. (Laurentiu C. Badea)" <[EMAIL PROTECTED]> wrote:
There's no reason to separate those two sections. They're exactly the same thing.
I believe they are functionally different
I still don't see why. Processing of the two sections would happen after authentication, and you would like to control fail-over/reject processing from one section to another. The module configurable failover code already does this in the "post-auth" section.
You still haven't given reasons why they need to be *separate* sections.
They don't need to, from the server's point of view. They should be, to help the user better classify the operations the server is doing.
I believe it may be a good idea from the server's architecture point of view as well, but it could be somewhat of a stretch since I don't really know how freeradius was designed.
That's not a bad idea, but I'm not sure where it would be useful. Do you have examples?
It's mainly a performance improvement. Under high load, to maintain the fastest response time, the extra time taken to (write log file + detail + sql) becomes significant, and since we already have all the response data, we might as well send it before we do that.
No. 100% no. This will NEVER happen in FreeRADIUS.
The Accounting-Response can only be sent if the accounting information has been stored somewhere. Losing the data is very, very, bad.
To put it another way, it doesn't matter how fast the server is if it's not doing what it's supposed to do. Logging accounting data is a REQUIREMENT for the server.
This is true if we are talking about accounting. But we were talking about the authentication (pre-auth, auth, etc...), where this could indeed be an improvement. It's not an all-or-nothing situation either, this could easily be a configurable option.
XML is impossible for the average human to edit.
It is indeed very verbose but has certain advantages. It has a very well defined structure, easy recognizable syntax and is very extensible.
How exactly is this different from the existing configuration files?
You have not given reasons why XML is *better* than what we have now.
It is a standard way to store data that has become mainstream. It supports all sorts of data and extensions, it is verifiable (via DTDs) and probably easier to read in the server since there are libraries for it available for almost every language.
Due to that, it can also be easily machine-generated using standard software tools, something that could be a benefit when maintaining hundreds of clients or realms, or for a web-based freeradius configuration editor.
Doesn't matter all that much though - I expect the current config files can also be generated from XML using XSLT if need be.
-- L.C. (Laurentiu C. Badea)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
