Re: Proof of concept structs for 2.0

[Adam Thompson <..hidden..>]

Chris Travers wrote:
> Here are some proof of concept struct definitions for 2.0.  What do folks think?

I'm assuming you are indicating data types, not literal strings of '$' 
et al., right?  Working on that assumption, for now.

> Also do you like right-justification or left justification of hash keys?

Either works for me.  I'd probably pick left-justification because it's 
easier and I'm lazy.  Plus if you use tabs it won't break horribly when 
using proportional fonts.  (Not that I do so particularly often, I'm 
just saying...)

> struct LedgerSMB::User, {
>         role_prefix =>  '$', # formerly from $request
>            username =>  '$', # normally we had to get credentials
>               roles =>  '@', # formerly from $request

Can't $role_prefix be dropped if we have @roles?

>                 dbh =>  'DBI' # formerly from $request

I can honestly say that I don't care for the current method of 
maintaining sessions... not being able to look at things in two windows 
simultaneously is occasionally a royal P.I.T.A.  I feel the burden of 
serialization (process, not data) has been pushed out onto the user, 
whereas IMHO it belongs in the web app framework.

Also, doesn't doing it this way completely prevent session pooling? 
Obviously you don't want multiple users crossing back and forth, but if 
I have multiple sessions open because I want to look at multiple things 
at the same time, all under the same userid, and each web request is 
atomic w.r.t. the database anyway... session pooling index by userid 
should be possible under those circumstances.

[Oops... see below.]

> struct LedgerSMB::Web::Request, {
>      params         =>  '*%', # formerly top-level hash
>      method         =>  '$',  # GET/PUT/POST
>      headers        =>  '*%', # Defined for the interface
>      url            =>  '$',  # full url requested
>      script_nsp     =>  '$',  # namespace of the script to run
>      dispatch_point =>  '$',  # formerly 'action' on the top-level
> };

I realize that CGI.pm may not be in use forever, and there is therefore 
some value in abstracting its interfaces instead of calling them 
natively, but is it worth the extra setup code?  What about non-web 
requests, e.g. thick clients - does this concept make writing those 
clients easier or harder?

> struct LedgerSMB::Session, {

[Oh.  Ignore my earlier comments about dbh in the ::User object.]

I would probably combine this with ::Web::Request - if we're using some 
sort of web-based infrastructure, the two are inextricable, and if we're 
not (e.g. thick client), will we need to keep track of the ::Session 
object at all?

> struct LedgerSMB::Web::Form {

Same comments as about ::Session apply here, too.

> struct LedgerSMB::Auth, {
> subclass LedgerSMB::Auth::HTTP_Basic...
> subclass LedgerSMB::Auth::HTTP_KRB5....

Similarly, I would not expect this to be something that needs to be 
exposed to the application innards.  Either the web framework takes care 
of it, or something else does, and the ::User object is the result of 
the authentication process... I would also probably consider it an error 
to treat a user suddenly switching auth mechanisms from one request to 
the next as a single "session".

Now you tell me where I misinterpreted things or am making up demons of 
smoke and mirrors out of whole cloth.  :-)

--
-Adam Thompson
 <..hidden..>
 (204) 291-7950