[Typo3-dev] LPE-some ideas

["Jörg-Alexander Roth [mediaDIALOG]"]

Hi Sebastian,

why so complicated?

First of all I *could* get very deep into detail, but I'm sad to say 
that I can't because of an NDA I've signed. But I'm able to give some 
more or less detailed hints...

Second I have to agree with the three parts: We've got a TYPO3 
installation somewhere, send the data to a different server and the 
final *page* will be shown there.

So do we need another T3 install on the live system? I don't think so. 
Let's get the idea behind a LPE. TYPO3 stores content of all kind in 
database. It uses a chache concept to retreive information once and not 
for each user browsing the site. Why? To get it faster and more 
reliable. Your idea grabs just a identically database to reproduce the 
content.. Doh - do we get redundant? What's up with the cache?

Your idea is great, but imho way too complicated.

Let's see what we've got: TYPO3 with the ability to produce static 
files. Plain HTML. Currently only on the system where T3 runs. Bit 
buggy. Wouldn't it be quite easier to publish those static files to a 
live server? Wouldn't it be quite easier to modify T3 this way?

So what's needed for that?
- Publish whole site or single branch/page
- Publish now or scheduled
- Throw an eye at the workflow
- Include all related files or only new ones
- Form included so generate automatically PHP files
- Access flag set so include login form
- Extension used so functionallity would be added

Ah, we've got a problem. The extension principle of TYPO3 would be a bit 
harder to solve.

For the layer stuff just fire up a connection to the live server, write 
the files and close it.

All internal stuff could easily handled by comments or special meta-tags 
within the HTML files (the big cms do so) IF needed.

What do we get?
A lightning fast plain HTML-site with all functionality, updated from a 
remote system somewhere. CPU and memory consumption will be very low.

And: You don't have that much of work!!!

Just take a look at www.chip.de - this shows exactly the mentioned 
way... or take a look at some VIP GAUSS installations like 
www.ihk-muenchen.de

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).

Regards,

Jörg

Sebastian Kurfuerst schrieb:

> Hello,
> I had some thoughts about a LPE because I will need it in a project 
> and so I made a concept for me how to do it. I try to explain my 
> thoughts to you because I hope you can make comments what's missing, 
> what's good and maybe you want to help implementing it because I think 
> it's a lot of work.
>
> OK, then start:
> I will use the term "Client" for the computer where the BE user is 
> editing the content, and the term "Server" for the computer which will 
> present the website to the clients because I don't know which part is 
> called Live and which Production.
>
> Anyways I think you agree that a LPE has three parts: The client part, 
> the transport layer (between the client and the server) and the server 
> part.
>
> Now some general stuff:
> **Client**
> In the pagetree, there needs to be a new symbol which shows if the 
> page on the client
>     a) doesn't exist,
>     b) is in a different version,
>     c) is current
> compared to the server pagetree.
> I think it is sufficent to create a new button on the pages: "Publish" 
> and "Publish with subpages". Also there needs to be a new section 
> where you can delete pages on the server which are deleted on the 
> client, too. Maybe there should be a popup when deleting a page if the 
> deletion should be also done on the server immediately or later.
> There needs to be a new field in tt_content where the PID of the 
> corresponding server page is stored. I don't know if we need that for 
> records too.
>
> ?? Do we need a field where the server id of the records is stored?
>
> **Transport Layer**
> I think it is needed to encrypt the communication between the client 
> and the server because if there is no encryption, everybody with a 
> little knowledge can inject pages on the server and hijack the server. 
> There are two types of encryption: Public-key and shared-key 
> encryption. I don't have any knowledge how to do public key 
> encryption, so I thought of a shared-key encription.
> The problem of a shared key is that the client and the server need the 
> same key. To make the shared-key encription as secure as possible, it 
> is good to use a kind of one-time-pad, so there is a new key every 
> transmission.
> That leads us to the next problem: how to make sure to generate a new 
> key similar on both systems. Because I didn't know how to do it, I 
> wanted to generate the key on the client and the key is then sent to 
> the server. I think this needs a little more explanation, so I show 
> you a (possible) communication between the client and the server.
>
> C: Generation of a random number of new one-time keys and insert them 
> into the database keylist.
> C: Creating an array with the data in it and all the newly generated 
> keys.
> C: Serialize that array and save the checksum of it into $checksum_A.
> C: Encrypt that serialized array with some encription algorithm and 
> delete the used key out of the database.
> C: Send the string to the server.
> S: Get the next key out of the key database table and delete it.
> S: Decrypt the string, make a checksum of the string into $checksum_B 
> and unserialize it.
> S: Insert the new keys into the database table.
> S: Do the action requested by the client.
> S: Encrypt the returned values and the checksum $checksum_B.
> S: Send them to the client.
> C: Decrypt the data and check if $checksum_A == $checksum_B.
> If unsuccessfull, resend the data.
> Maybe the checksum of the "answer" should also be sent to the server 
> again to make sure the communication was successfull.
>
> I hope this explains what I wanted to say.
>
> ?? Is it a good idea to use public-key encription=?
> ?? Which encripiton algorithm to use?
> ?? Should the checksum of the answer be sent back to the server to 
> make sure the transmission was successful or isn't that necessary?
>
> **Server**
> The server is a kind of "stupid", so it just does what the client 
> tells him and the logic which data shall be transmitted will be on the 
> client.
>
> **Database Tables**
> -for the caching of the server checksums of the pages to see which 
> pages are current, altered, new,...
> -exclusion table, to make sure that not all the records are 
> transmitted (like be-users)
>
> On later versions, it could be possible to make a sync between the 
> server and the client, but I don't know if it makes any sense. What do 
> you think?
>
> **Sync**
> Synchronization should not be so difficult.
> At first, we will get the MD5 checksums of the content elements on the 
> server, then we will run a kind of diff and then the upload starts. At 
> the end, the checksums will be checked again to make sure the 
> transmission was successful.
> The problem is how to transmit data on the file system. Do you have 
> any thoughts how to deal with that effectively?
>
> Yeah, that are my ideas. What do you think of them? Do you have things 
> to make better, things you would change completely? Do you think this 
> could be useful to you, too?
>
> I hope you understood me, I'm no native speaker.
>
> Sebastian
>