luxor / chora

Cynic cynic@mail.cz
Thu, 09 Aug 2001 08:40:30 +0200


Hi there,

I'm thinking about luxor / chora integration, and since I'm only 
getting to know chora, I've got a few questions...

<soapbox>

First, let me say that the fact that code in Chora that actually 
does something (i. e. besides declarations) is spread among files 
directly requested from browser and files included from these 
makes it really hard to understand the code. Looks like the only 
one who's been working on Chora so far is Anil, so this is 
understandable (no need to read other people's code, no problems),
but I'd be extremely happy if it'd be possible to reorganize the 
flow so that the includes contain only class declarations etc. 
Opinions?

Second, Chora is terribly heavy. For example, a CVSLib_File object
for a file with two revisions and a single branch (HEAD) contains
seven full CVSLib objects. print_r() representaion of that object
has 45kB, and it doesn't include the method hashes. I know this 
doesn't say much, but you get the idea. Are such heavy objects 
really necessary? I believe this slows down execution significantly.

</soapbox>

Now, back to work. 

1) What variable or public object property contains / accessor returns
the filepath as contained in the URLs? To make myself clear:
given this URL, I want to get the "/luxor/images/back.gif" part:
http://localhost/horde/chora/co.php/luxor/images/back.gif?r=1.1.1.1

2) I've read in the GOALS file that you want to abstract the diff
handler so that e. g. image revisions are displayed side by side.
IMO the first step in this direction would be generalizing co.php
by moving the actual output of the revisions to the appropriate
methods in the MIME handlers. That way checkouts of images could 
look just like checkouts of html/php/text files:

    $raw = = Horde::getFormData('raw', 0);

    if (0 == $raw) {
        $pretty->renderWrapped();
        # or whatever
        # will do:
        # include $registry->getTemplatePath() . '/common-header.inc';
        # include $registry->getTemplatePath() . '/checkout/header.inc';

        # print '<image src="...&raw=1" ... />' for images, the first 
        # branch of the "if ($pretty->getType()..." in the current
        # implementation for text/*, and whatever is appropriate for
        # other types 

        # include $registry->getTemplatePath() . '/checkout/footer.inc';
        # include $registry->getTemplatePath() . '/common-footer.inc';
    } else {
        $pretty->renderRaw();
        # or whatever
        # e. g. for images, this would basically be the "else" branch of
        # the current "if"
    }

Now luxor questions.

1) I should probably just wait till I get some sleep, but out of sheer
curiosity: let's say luxor would be registered handler for .php files.
Scenario:

index.php includes 'foo.inc' and 'bar.inc'. index.php calls blah(), which
is defined in foo.inc 1.1, and bar.inc 1.1.5 (moved from foo.inc).

index.php   2001-05-01  1.1
            2001-06-01  1.2

foo.inc     2001-05-01  1.1
            2001-05-15  1.1.5

bar.inc     2001-05-01  1.1
            2001-05-15  1.1.5

When you checkout index.php rev. 1., and display the ident ifno for blah(),
what should it display w. r. t. its definition? Should it display "defined
in foo.inc" or "defined in bar.inc"? I. e., should it base the ident query
on the date of either revision? The problem is, that unless I overlooked
something, either way would mean that if you got back to index.php going 
through several different files, always querying the latest concurrent 
revision of a file linked linked to the current one, you could end up 
several revisions away from the original one. I guess the way to go would 
be to get the time just before the next revision to index.php was checked 
in, and do checkouts based on the timestamp from then on.

Do you see any problems with this?


cynic@mail.cz
-------------
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
    - Book of Installation chapt 3 sec 7