On Thu, Mar 1, 2012 at 12:47 PM, Michael Richardson
<..hidden..> wrote:
>>>>> "Chris" == Chris Travers <
..hidden..> writes:
>> My proposal is to move all of the wrapper .pl files out of the
>> root directory into a directory which could be called "htdocs" or
>> something like this.
>>
Chris> into a src directory. I don't see that happening before 1.4
Chris> because it would make svn merging a big of an additional
Chris> pain, but I like that idea. The current directory structure
So the idea would be that "." would still be DocumentRoot?
I agree that it has to be coordinated well because of the SVN pain.
Perhaps this is a reason to call something "2.0" :-)
No, src would be document root once that happens.
Chris> is in fact very developer friendly, and I am not sure I want
Chris> to force a lot of hacks in that way to deal with it. So I
Chris> don't foresee the specifics here being accepted.
I actually find it very developer unfriendly :-)
I have to configure a system apache, and a postgresql. There is no
single script to start me off working. I hope you will have a chance
to look at the skeleton stuff: it saves me time, and therefore I will
continue to adapt it to my local needs.
Well, if we start setting targets, we may be able to do more with putting the main stuff in htdocs and using a .htaccess file. However, I want to make sure we have had a major release or two with stable Apache configs so that this does not cause problems for those upgrading.
Chris> However, I think the problem you are trying to solve is a
Chris> real and a valid one. I just think we can solve it without
Chris> making it hard for me to run 1.2, 1.3, and 1.4 in parallel at
Chris> the same time.
By parallel, I guess you do not mean making it easy to have three
directories with three databases -- because I do not think it changes
things.
I guess you mean that it makes it easier to be able to apply patches to
older versions?
It means that I can do development on 1.4, use 1.3 in production, and provide support for 1.2 without having to resort to tricks with PERLLIB. The only reasonable way to handle the .pm files in this case is locally in the directory (i.e. in the tree the way they are now). Moving the .pm files to PERLLIB means that we can effectively only use one version at a time on a system. It's great for some things but it's bad for those of us doing development and support.
Chris> Here is my suggestion, which is to focus on tweaking the make
Chris> process rather than the current file structure:
Chris> 1) Tweak the Makefile.PL so that make install ONLY installs
Chris> the LedgerSMB.pm, and the files in the LedgerSMB directory.
You mean, I think, installs into a system directory?
Something like vendor_perl (for rpm) or site_perl (for installs from CPAN).
Chris> 2) Create a separate make install webapp target which accepts
Chris> a directory in some way and allows you to install/configure
Chris> the web app in a directory of your choice. This would copy
Chris> the top level .pl files, the bin/* files and the UI
Chris> directory. Note that scripts/* is moved into
Chris> LedgerSMB/Scripts for 1.4 so that would all go into somewhere
Chris> in $ENV{PERLLIB}
so, I suggest that it be a script, and I suggest that the distro
packagers are going to want to run this... on the target system,
after asking the admin what directory.
How about "DOCUMENTROOT=/opt/ledgersmb make install_webapp"?
Chris> Long-run, the ideal thing would be to get rid of all the
Chris> files that go into the web app directory except for a single
Chris> request handler.
I have been hoping that lsmb would grow better URLs such that I can more
easily tell my less clueful colleagues,
"go http://accounting/reconcilliation/1060" rather than "click here,
click there, etc..."
Maybe others want the opposite.
But, what you mean by "single request handler"? Because there could be
stuff to the right of that request handler piece.
What I mean is that since Apache and some other web servers support having a single script that handles and processes all requests for a directory, we could reduce this to a single file or so, with the work done in pm's which, in a production server would be safely in PERLLIB.
>> Now, almost all of the real functionality is now in the bin/
>> directory, and this would be among the things that could go
>> somewhere else when installed, rather than being under
>> DocumentRoot.
>>
Chris> I don't see us doing this with the bin/ scripts. Sorry. The
Chris> reason is that these are big scripts that came from
Chris> SQL-Ledger and they are pretty brittle. I would not be
I didn't understand that the bin/* is the legacy.
Yes, do not touch! :-)
Chris> 2) Support a make install-based approach. Right now make
Chris> install creates significant supportability issues. However,
Chris> if we allow one to make install, it could be downloaded into
Ah, you thought perhaps I wanted to insist on "make install".
Just the opposite... I want to *support*, but as a developer, I don't
want it at all.
What's the problem with make install?
>> My reasons for suggesting this are twofold:
>>
>> 1) depth-in-security: misconfigured web servers can not allow
>> writing to things they can not see.
Chris> I am not quite sure I understand your concern here.
If the file isn't in DocumentRoot, it's much harder for web server
to return it, or write to it.
We try to be pretty sane with file permissions. Long-run however, I agree that all this should go elsewhere.
Chris> Right now the LedgerSMB logic only works for web apps, but we
Chris> are putting a lot of effort into trying to ensure that you
Chris> could build GUI's for it also. The current core logic has a
Chris> bit of a problem in that the way it is installed only works
Chris> for a web app and if you make install, that causes
Chris> supportability issues. I think getting this sort of thing
Chris> working for 1.4 needs to be a priority.
+1000.
Also, RESTful scripting and other stuff.
The RESTful stuff can be shimmed in. There's no reason we can't do that. The big issue is that the logic is only accessible to the web server, so.....
Best Wishes,
Chris Travers