OT-ish: Dreamhost and LiveCode?

Richard Gaskin ambassador at fourthworld.com
Sat Aug 1 20:03:20 EDT 2015


Alex Tweedly wrote:

 > If the issue is just with fonts, why have the flag be "-g" to turn
 > off all graphics ?
 > Why not "-f" to turn off font initialization ?

"g" is for greedy. :)  To use fonts requires graphics support, and since 
most CGIs don't use graphics at all it seemed expedient to consider an 
option to turn off all graphics-related operations during init.

That said, you do have a compelling edge case here:

 > I have a number of scripts that render graphics (resize images,
 > on-the-fly thumbnails, etc.) but none that need to render fonts,
 > and I'd imagine there are various other reasons why you might want
 > to keep some graphics capabilities without ever needing to do
 > anything with text+graphics on a server

Of the subset of CGI scripters who need graphics, there may be others 
like yourself in the subset of that subset who don't also need fonts.

If you feel strongly about that please submit the proposed "-f" as a 
comment in the report:
<http://quality.runrev.com/show_bug.cgi?id=13983>

I don't have a strong opinion either way, but my main interest is in 
finding a solution that optimized boot time as much as possible.  If 
non-font-related-graphics init is trivial, I'd be fine with a 
no-font-only option.

How much of a performance difference have you measured specific to init 
time with v7.x over v6.x?  And on which hosting service?  I'm keeping 
detailed noted on this until it's resolved.


 > btw - I agree with Malte it should (somehow) be done per-script
 > rather than more globally.

Malte's solution was to handle this in LiveCode scripting, but my 
understanding is that font and other graphics init happens before script 
interpretation is possible.  Attempting to move that init process until 
after the script subsystem is initialized seems like a lot more work 
than I'm hoping for with a simplest-to-implement interim solution.

Fortunately, for the subset of CGI scripters who need graphics support, 
and the subset of those running on configurations that exhibit this sort 
of slowdown, and the subset of those who need to mix graphics and 
non-graphics scripts, there are at least two options that come to mind, 
possibly more:

If you put the scripts that need graphics support in a different folder 
from those that don't, just use a different .htaccess file in each.

If you're in the subset of the subset of the subset of the subset who 
absolutely must put all scripts into a single folder whether they need 
graphics support or not, remember that the labels used in the .htaccess 
directives for file type handling are purely arbitrary, allowing you to 
support two (or three or a hundred) different file types, which could be 
distinguished by whether they need graphics support, e.g.:

   AddHandler livecode-script-without-graphics .lc
   Action livecode-script-without-graphics /cgi-bin/livecode-server -g

   AddHandler livecode-script-with-graphics .lcg
   Action livecode-script-with-graphics /cgi-bin/livecode-server


Please keep in mind that this option I've proposed, whether it be "-g" 
or "-f" or whatever, is just a quick solution for the relatively small 
number of people who have reported serious increases in init time. Mark 
Waddingham has already expressed a keen interest in making the engine 
smart enough to handle these things without us having to change anything 
at all.

My interest here is in finding a suitable short-term solution that could 
be done by the engine team in two hours or less.  Given the necessity of 
using v7 on modern 64-bit servers, and the growing interest in 
client-server systems, it would seem even an imperfect solution today 
would be better than a perfect solution several months from now.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the Use-livecode mailing list