debian-sf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Debian-sf-devel] New alexandria BASELINE: should we open up a new


From: Mark Constable
Subject: Re: [Debian-sf-devel] New alexandria BASELINE: should we open up a new one ? Where ?
Date: Wed, 7 Nov 2001 15:42:51 +1000

On Tue, 30 Oct 2001 07:46, Tim Uckun wrote:

> >Since the current SF software was always written with the intention that
> > it was centered around SF.net, if we were to jettison that preconception,
> > we could make huge changes and cleanups to the codebase pretty quickly.
>
> I'm in if you need help. I am pretty good at php coding and decent at perl.
> Right now I am 50/50 as to whether I want to continue to try and SF working
> or go on to something else. TUTOS, phpgroupware and projeckt (a zope
> product) seem to have limited capability to do some of the stuff SF
> does.  None of them have the depth of SF but all of them offer a calender
> module.  I would rather have a pure php solution myself so I would welcome
> the challenge of working to make SF better.

I started a complete OOP rewrite of the code and got thru
the basics.. maybe 10% to where it would at least run and
allow me to redo the presentation in a sane way. I notice
the sf.net frontpage is still missing the narrow shaded 
graphic edge on the RHS of the LHS menu... plus the top
set of menu items only stretch half way across the LHS side
menus when making my browser full screen. I extracted 50%
or more of the hardwired values in that 10% core and was
up to the basic cut n paste grind of converting the rest
of the modules... ie; I mostly got past the WTF stage and
was onto the brainless/boring cut n paste stage. I just
don't have a spare 1000 man hours to complete the job. I
reckon I've spent 100 hours pouring over the code so far
so I have a reasonable idea how it fits together, or did
a few months ago anyway.

The most elementary thing I needed was the ability to
do virtual hosting with the Debian package, where there
is a single codebase but a seperate db for each vhost and
within that context could run as many sub-domained hosts
per virtual host as needed. This part was easy but when I
tried to make matching cosmetic changes so each vhost could
control their own appearence... well... a month later I 
rewrote 10% of the entire code... and gave up... for now.
There seems to be some resentment in PHP circles to adopt
fully OOP principles so I'm adopting python as my first
choice language from now on.

If anyone wants what I have done so far then let me know
and I'll try to dig it up from the bowels of my HDD.

--markc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]