-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Emiliano!
- --On 06.03.2002 15:43:46 +0100 Emiliano wrote: >> What do you think about this idea: Would it be possible to leave the >> MidCom's in the file system, not including it from snippets, but from >> the files directly? I'm not sure, which impact this would have on the >> application (and on Midgard itself), but this would make development >> a lot easier. CVS Support would be really easy there. > > That's what I was thinking. It'd still need mod_midgard support to > make the DB connection available, so there's work to be done thinking > up an architecture/interface for this. Not only for that, but I'd like to have it fully transparent on the PHP layer whether you have file storage or not. At least for read-only access. >> If this would be possible, I would like to see it incorporated into >> midgard as directly as possible, because I see a lot of performacne >> Issues coming to us here, along with some othor minor PHP things. > > Hey, you got my vote. You know, that I've no idea about midgard C-source code? *lookinginnocent* >> I'd really appreciate your ideas about file storage at this point, >> because I'll soon start implementing a first proof of concept of this >> whole thing to see, whether it could work. > > I don't have any concrete plans about file storage other than that I > want to have it. Trade-offs will have to be made about flexibility vs > performance (filetemplates were flexible but very slow), readeability > (FTs were not really easy to read/code), and mounting issues (at what > point in your URL tree does the app hook in, how does it tie in to the > selected host/style), and authentication forceing (midgard pages can > demand authentication, not so easy for phase 9 work). I would > personally be OK with the app having to be bundled of sorts to > pre-determine what elements were appliccable (this would be akin to > MMP caching out the paes) in order to win some performance; one thing > we'll want to avoid is having a lot of disk reads/seeks. What about a small scale solution for this: Filestorage only for Snippet(dir)s. This could also be limited for SG0 "mounting". This way everything would be read-only, but you could still access it directly through the midgard layer. Instead of editing it with asgard, you use vi ;). Problems there: Replication... And one thing else: MidCom assumes, that the end-user can modifiy a part of the component (layout and configuration parts). They have to stay either in the Midgard DB or have to be stored somewhere else. I'm not sure what to do here. If you design the whole thing specifically for MidCom, it could be possible to still use snippets for the whole thing, but a complet rewrite of the naming conventions would be neccessary for that. I have some ideas about that, but I've to think it really through first. Perhaps something like this: The MidCom itself is in file storage, accessed to sepcial Midgard Functions. It still consists of php code, which gets included like a snippet in the runtime environment. Configuration hooks can be easily done through the naming convention (de.linkm.newsticker...). Style deferral to external components is another problem here, perhaps some advance layout things could help here. Live long and prosper! Torben Nehmer - -- Torben Nehmer, Munich, Germany http://www.nathan-syntronics.de, mailto:[EMAIL PROTECTED] PGP Public Key ID on wwwkeys.(de.)pgp.net: 0x7E9DE456 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8hi77JPh4Kn6d5FYRAqujAJ4wIwFwpNzLJAt6f+XGg7UECKZ9JQCfdw0K ++9qFIPvsIB6oNWuUwdZOyY= =aKTE -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
