-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Emiliano.
- --On 06.03.2002 16:50:33 +0100 Emiliano wrote: >> 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. > > Sounds good, but requires a lot of up-front thinking before we > actually implement anything. For me, it isn't necesary that > file-based midgard apps be manageable (editable) through the Midgard > API. Agreed, as long as the problems below are solved. >> > Hey, you got my vote. >> >> You know, that I've no idea about midgard C-source code? >> *lookinginnocent* > > Not a problem. Actually getting things implemented is a pretty minor > issue. Getting the concepts right is hard. Sure. That's why I posted the MidCom Draft RFC. I'll continue working on the draft the next days and post an update as soon as it incorporates all new ideas. (see below...) >> 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 ;). > > Something like that, but I'd prefer it if there would be a way to have > apps fully file based. Untar, config, run. Surely guru-compatible *GG*. More end-user-like would be an apt-like interface (through an midgard site or so), that enables you to manage the whole package installation thing more sophisticated. If you use packages in a similar way then i.e. Debian does, you could even realize things like post-install scripts and so on. >> Problems there: Replication... > > I don't see this as an issue. Apps will be long-lasting, low-updates. > Tar + download or rsync will do me fine. What if I replicate a site from server A to server B? This can't be done automagically through a repligard file anymore, I'd have to ensure, that all MidComs are installed. The Snippet approach wouldn't require this. >> 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. > > Well, that's the hard part :) Ideally, we'd want to have a reliable > mechanism where style info could be file and/or DB based, while the > app lives in a file. This doesn't preclude the way things work now in > Midgard, of course. It'd be an alternate form of deployment. With the right packaging, you could do this. The Post-Install-Things create the neccessary Snippet Trees that don't come from the file storage, but as in the current draft from a defined snippet dir. An alternative would be dynamic styling: You have the default style on the file storage, if you want to override this, you have to explicitly accociate a style to it, which is used at runtime to show up the elements required. A fallback to the default style could also be done in case the style doesn't contain the elements required. 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 iD8DBQE8hkOiJPh4Kn6d5FYRAj6DAKChxeCAlw33NmgPZU0pQDo4IC0DiACfc8A4 k7BcI4I3031ah0nB2QKRyLo= =jHI+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
