[prev in list] [next in list] [prev in thread] [next in thread] 

List:       midgard-dev
Subject:    [midgard-dev] MidCOM source out of the snippets and back into the FileSystem?
From:       Torben Nehmer <torben () nehmer ! net>
Date:       2004-06-21 7:32:36
Message-ID: 8D647E26C8E0489DF674B459 () [192 ! 168 ! 0 ! 1]
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I propose to move the whole MidCOM source out of the MidCOM database
back into normal PHP snippets that get include()'d.

Short version of the reasoning:

* Easier development on all fronts:
  - CVS commit messages clean
  - source backports from CVS HEAD to a stable branch far easier
* No more hacks on tools like HTMLArea to work out of the DB
* Improved performance, MidCOM currently requires DB accesses in the
  magnitude of 100 to get the whole source running, as a rough guess.
* Easier debugging, relieves us of the code-eval hell
* Easier source distribution/upgrading, as Repligard is out of the
  chain.
* Employ your favourite PHP Editor again

As MidCOM Head Developer would like to do this as a primary goal for a
release titled "MidCOM 2.0", which will follow the 1.4.0 release
currently underway. I don't think (contrary to the IRC log below) that
it would be wise to make such a big change in the old 1.x strain on a
short notice like this.

Doing this, it will require a clear, predifined directory hierarchy.
Also, this would make source distribution using RPMs/DEBs or even an
internal packaging mechanism like Typo 3 does (they even have a
web-interface for it integrated in their CMS) the easiest thing of the
world.

Summarizing: I desperatly want this, (along with a rewrite of certain
parts of the core, which start to outgrow me), and if nobody of you
don't have a serious objection against this move this will be the next
priority on my todo list. 

IRC log excerpt:

- ---cut---
<torben> what would you think of moving midcom's source code back into 
         the filesystem as simple, plain, old .php files?
<torben> with the primary goal of making editing, cvs stuff, upgrading

         and the such easier?
<torben> repligard isn't just the most end-user friendly tool
<tarjei> I've been thinking a bit around that as well
<tarjei> I'm not sure
<tarjei> I am too addicted to filesync to be without filehandling som
we 
         need to have something like it.
<tarjei> do you know how plone does this?
<torben> no
<torben> i can only speak of typo 3
<torben> they basically have everything in the FS, with their own 
         extension repository, which works roughly like APT
<torben> you can, starting off from the regular admin UI, get package 
         lists from the official distribution sites
<tarjei> if we could find a way to do replication using this, then I 
         would be +1
<torben> you click an install button, typo3 dl's the extension and does 
         a local-user installation
<torben> no more messing around with repligard, which is clearly not up 
         to the job i have for it with midcom
<torben> just look at the current commit messages, which are hell
<torben> it gets more difficult when you try to "back-port" a given 
         change from a midcom-head revision into midcom_1.3 branch
<torben> i had to resolve repligard-induced conflicts each time
<tarjei> I think part of the problem is that in snippets, repligard 
         should relate to paths, not guids
<torben> not neccessarily, mostly i agree, but not always
<torben> i actually think, that midgard should have deprecated the 
         object IDs with the introduction of repligard
<torben> and having real program code in the database isn't that good 
         either
<torben> most optimizers cannot take advantage of this, and the 
         unneccessary db overhead is hell too
<tarjei> true
<torben> not speaking from the time you as author loose because you
ahve 
         to constantly modify things like HTML-Area to work from
outside 
         a db
<torben> to be honest: i want to get rid of this mess
<torben> it makes midcom's life a lot more difficult than it needs to be
<tarjei> wouldn't it be ok to move midcom out of snippets today?
<torben> from me as midcom head developer: yes
<torben> clearly yes
<torben> it will be quite some work to get everything back up, but 
         actually thanks to the $midcom->load_snippet wrapper, it won't 
         be too bad
<torben> oh, one more thing we would get out of this: no more code-eval 
         error message horror
<tarjei> if you can come up with a good system for where to put files 
         etc than this could work
<tarjei> but: We should find a way to keep it replicated. 
<tarjei> btw, how would this work w.r.t. midcom speed?
<torben> i don't think that you'll like to have automatic replication
of 
         the source
<torben> w.r.t?
<tarjei> with regard to 
<torben> it would improve it 
<torben> i could even imagine, that this will be quite some improvement 
         compared to the db version
<tarjei> well, if you're so for it, why not do it?
<torben> currently, MidCOM requires DB accesses in the magnitude of 100 
         per request just to load the source, including default styles 
         and L10N DB accesses
<torben> well, i'm lead developer after all, but that does not mean
that 
         i don't want to hear what the community says about this.
- ---cut---

Live long and prosper!
Torben Nehmer

- --
Torben Nehmer, Guenzburg, Bavaria, Germany
http://www.nathan-syntronics.de, mailto:torben@nehmer.net
PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc
-----BEGIN PGP SIGNATURE-----
Version: Mulberry PGP Plugin v3.0
Comment: processed by Mulberry PGP Plugin

iQA/AwUBQNaPFST4eCp+neRWEQIJ2ACfTs1RJ9atCtOwJReo/ucBE9fz6aMAmgLe
eOSN2jVe40hMsEu/ySDf5pDS
=urCv
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@midgard-project.org
For additional commands, e-mail: dev-help@midgard-project.org

[prev in list] [next in list] [prev in thread] [next in thread]