[chora] luxor / chora

[Cynic]

At 17:53 8/10/2001, Anil Madhavapeddy wrote the following:
-------------------------------------------------------------- 
>On Thu, Aug 09, 2001 at 08:40:30AM +0200, Cynic wrote:
>> 
>> 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?
>
>I must confess I have no idea what you are saying here ...
>what do you want to do exactly?

A quick example: $fullname jumps out of nowhere in co.php. 
Putting 

$fullname = Chora::getFullName();

or something like this in co.php would de-obfuscate it. You don't 
gain that much if you put it in lib/base.php. 

This is really a simple example, but the deeper you dive into the 
code the harder it gets to keep track of what comes from where.

>CVSLib sort of evolved as I got to know CVS, and I've been
>pondering about how to generalise it to support Subversion and
>Perforce as well.

Subversion would be rally nice. BTW, they plan to reach MileStone 3
next Wednesday.

>Reorganisation with this in mind would be a good thing;
>anything else to fix up what is currently there is probably
>not worth it if it's a fundamental reorganisation.

I'm not sure if I got this right: you mean that a reorganization
that wouldn't allow to snap in other versioning systems (easily)
isn't worthwile?

>> 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.
>
>This can probably be fixed pretty trivially by changing the CVS
>object to a global variable, or just request a singleton. I'll
>look at this.

Great!

>> </soapbox>
>
>No need for rants :)

I meant "this may not be strictly technical as I don't know Chora well
enough yet, so don't take it too seriously".

>> 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
>
>URL handling is also really messy right now; I'm actually
>working on this today, so you'll have a different answer after
>I commit shortly.
>
>I want to hook in this URL creation as a registered method
>in the registry, so external apps can also link into Chora.

Yeah, I found out latter that physical path is in $fullname and the 
filepath from URL is in $where. When I started writing phLXR I also decided
to use PATH_INFO for this, but it only turned out it just sucks. And since
the Chora URLs contain querystring anyway, it'd be easier if you could
just stick &file=whatever in there. You could save the code that gets the 
name from the URL. Not to mention problems with servers that don't support
PATH_INFO. Is that what you planned to do?




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