[Typo3-dev] LPE-some ideas

Sebastian Kurfuerst sebastian at garbage-group.de
Sun Feb 22 19:24:08 CET 2004


Hi,

> | ?? Do we need a field where the server id of the records is stored?
> 
> Definitely. On a per-page and per-content basis i think. That would give
> us a much higher flexibility.
The per-page basis is not the problem. The only problem I see is when 
you don't just deal with tt_content, but with other extension records. 
So maybe we need another database table where the ids on the livesystem 
are stored.

> Think about someone editing a page on the
> server (which should still be allowed to enable people to edit the
> content from different locations)
That's something I thought about but I don't know if this is realizable. 
Beneath, I think an LPE is just about seperating these two servers. 
Nobody says that the "client" shouldn't be accessible on the Internet.
> 
> The theory behind CVS or other version systems may be helpful for this
> concept, basicly it's good old branching and merging stuff.
> Maybe if a user logs in to the client, a "working-copy" is fetched from
> the server which updates all changed tables. On a "reload page-tree"
> this is done again, to show if something else changed which interferes
> with the client-side changes.
As I said, I think this is not necessary because the server-side is not 
allowed to change. A working copy to the client is an interesting idea, 
but I think we don't need it. We'll see.


> | ?? Is it a good idea to use public-key encription=?
> Do we really need encryption like that at all? It sounds as sexy as the
> term "XML" - i agree, but when we are just sending the appropriate
> backend user information through SSL, wouldn't that be enough?
What do you say about BE user information? The problem I see is that if 
the transport layer is unencrypted, everybody can hijack the server and 
this would be an enormous security hole. I didn't think about it because 
it is sexy but because it is a need IMHO ;) . Just imagine you have a 
cooperate website with a login area for employees. When there's no 
encryption at all, everybody can read what is just for employees.

> | ?? Should the checksum of the answer be sent back to the server to make
> | sure the transmission was successful or isn't that necessary?
> It seems to be a good idea. At least for debugging.
Yeah, maybe we can make this configurable.

> | **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.
> Still you need some logic on the server to handle the requests and to
> the encryption stuff. My thought on this was an extension which is
> installed both on the client and the server. They are like gateways to
> the rest of typo and we always know where the scripts are installed
> (typo3conf/ext/...)
Yeah, this was what I thought of. LPE should be one extension, where you 
can configure if it should act as a client or as a server. Because they 
have similar parts (f.e. transport layer).

> A part of those scripts however is not directly linked to nor recognized
> by typo - these scripts are triggered to do the neccessary changes to
> the tables, while the other scripts just do the new icons and click-menu
> entries in the page-tree.
Yeah, exactly.

> | -exclusion table, to make sure that not all the records are transmitted
> | (like be-users)
> Would this be neccessary? I mean you can exclude tables to BE-Users and
> they just would not be shown to the user. And if only individual records
> are transmitted to the server, that would only be those he is able to see.
Umm, I wouldn't use the exclude tables of the user. Just imagine we have 
a page where 1 table isn't shown to the user in the BE, but it is needed 
in the frontend (for example an entry of a link in a linklist). So it 
needs to be uploaded, too. So I would prefer an exclude system where you 
can exclude certain tables under certain conditions.

> | 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?
> I think it would, because on complex sites, it may be difficult to get
> an overview about all changed pages, an "sync all" option would be a
> great feature, maybe just below the "Reload-page-tree" link.
The overview of what changed is in the pagetree of the client. I would 
introduce a new icon where you can see if the page is updated/new/....
But of course a "publish with subpages" in needed.


> | The problem is how to transmit data on the file system. Do you have any
> | thoughts how to deal with that effectively?
> FTP? The table data can be passed to the above mentioned scripts, and
> the "fileadmin" resources could be transferred by FTP. Maybe with
> builtin zip functionality.
FTP... Is an interesting idea.

bye,
Sebastian





More information about the TYPO3-dev mailing list