[Typo3-dev] LPE-some ideas

[Rene Suthoelder]

i'm not a programmer at all, but i do know at least 2 different CMS which
work with staging and live server environment.

both systems i know work with one (or more) production server and one (or
more) live servers. the CMS are designed to handle heavy traffic, both in
front-end (website) and back-end (content production). (perhaps one of the
developpers could have a look at http://www.imperia.net/en/htmls/index.html,
that's the CMS i know best).

for example, the techies of imperia decided not to use (too much) dynamic
pages on the live server, instead create as much plain static html files as
possible since static files undoubtedly are served fastest on any given
hardware.
this is in contrast to broadvision's story server (the other CMS i know): to
handle higher traffic they add more expensive hardware (clustering) to serve
their mainly dynamic pages...

but both systems use the system of a divided server setup for the content
production and content delivery (both CMS can be configured to run on just
one server, though). main reasons for splitting: security, performance,
scalability.

ideas:

t3 would need to have "worker thread" on the live server to better handle
time triggered events (remove old pages, activate new pages, things like
that)

just my thoughts

rene

"Jörg-Alexander Roth [mediaDIALOG]" <mail at zeusmedia.de> schrieb im
Newsbeitrag
news:mailman.1.1077565714.27585.typo3-dev at lists.netfielders.de...
> Sebastian Kurfuerst schrieb:
>
> > I thought about this, too, but just imagine the following case:
> > I have a site without frames and the navigation is shown on every page.
> > I have the following page structure:
> > A
> > |.B
> > |-C
> >
> > I have published all of them as static html files.
> > Now I want to change something on page B, but I don't want to publish
> > the changes yet. Of course there is the hidden feature for that, but I
> > would have to duplicate the content element with one hidden and one
> > not hidden. Bad idea I think.
> > Now I create a new page D on the pagetree. So all menus of the pages
> > A, B and C change. So I have to republish the page B, with all changes
> > I made and I didn't want to be visible. That's the problem I ran into
> > when thinking about the possibilities I have.
>
> Well, recording or -storing- the changed values since the last publish
> process won't be that hard. Even if you do some really weird stuff, all
> changed records will be published. It doesn't matter if you change the
> tree, add new pages, sort them, upload new images and so on. Every
> process will be recorded and executed. Sure in some cases it will be
> difficult to handle it. But for the somewhat dynamic ideas you've got
> you will get in heavy trouble.
>
> >> - Include all related files or only new ones
> >
> > That's the biggest problem when including related files.
>
> As I mentioned above: Pic changed? Modified? Then send them along also.
>
> >> Static files will do the job. Creating an LPE is one thing but for
> >> the future development of T3 there should be an eye on the speed.
> >> Especially for the sake of larger sites (500+ pages and high visitor
> >> count).
> >
> > Yeah, and the best thing for that is having a second T3 installation
> > which just handles the FE, so we can use _all_ features of T3 IMO.
>
> Splitting FE and BE...nope.
>
> Yes, I do get the point. I know about the difficulties updating a menu
> and so on. Just a thought: SSI. Menu separated from the rest. Doh,
> that's low-level... :)
>
> But to keep up with your dynamic idea: Create a totally new frontend
> parser. Fill all data straight from xml which will be moved/updated on
> live server. Images, Text, Multimedia - everything's inside. Related
> files will be also moved. All features will be available, menu buttons
> are created automatically again on the live server. But there we got
> stuck again with the extensions.
>
> Conclusion: Won't be that easy at all and a lot of thoughts must be done.
>
> Regards,
>
> Jörg