Hi guys,
Jowell: Right now modetp already does a "file" storage type of storing the binary files. Which means it uses the file system and just store the filename on the database. Previously I used a lob but Luke advised me to use the file system. It has certain advantages like using copy of modetp will only need copy the filename rather than making a new copy of the binary data. So believe we will just use the "file" storage type on ETP 2.0 as supporting lob does not seem to give any advantage.
Having ETP mount a new instance for each folder has its benefits like you can have different ETP application type on a single ETP tree. For example /level1 uses the simple ETP app while /level1/level2 and level2 uses the FAQ ETP app. It also makes it simple to access ETP data via just simple URLS rather than /get-content?content_id=1234. You can also probably accomplish this via an index.vuh but it does make it more complex. It has its disadvantages such as traversing the ETP tree to get some data on a different instance. I have created a simple proc to the get the top most ETP subsection. This way I can create the main nav links above. See demo.infiniteinfo.com/modetp.
Alex: Right now modetp is able to accept file uploads even HTML files. This will be served up as HTML although it will be be merged with the template. modetp makes use of a visual editor which basically IE 5's dhtml edit mode on. It looks cool but I believe its not a long term solution. If you have a need to get Word like interface then the visual editor that is used in modetp should work. I think agree with Luke it maybe hard to support uploaded HTML and merged with a template. But ETP 2.0 should serve HTML pages without merging with templates possible.
All:
I think we should drop the support of ETP coexisting with subsite packages. This makes more complex stuff. We should just mount ETP on /foo then just use Host-Node map. Currently modetp seems to just run fine with this setup.
Anyway got to go I am kinda hungry its way past lunch time.
