Stephen John Smoogen wrote: > On Mon, Sep 8, 2008 at 10:50 AM, Michael DeHaan <[EMAIL PROTECTED]> wrote: > >> Now that Daryl Pierce has written rubygem-cobbler* for making Cobbler's >> XMLRPC API even easier to use for webapps, and I have already mentioned >> WebUI improvements are going to be a major focus of the next release, I >> am pondering /potentially/ making a future iteration of Cobbler Web use >> Rails. This seems easier to me in many ways that adding some new >> capabilities into the existing web app. >> >> The downside to this is there is no Rails in EL 4, but it is there in EL >> 5 (Rails 2.0.2 is in EPEL 5). This would mean if you wanted Cobbler >> Web, you'd have to install the Web app on a EL 5 or later server, but >> cobbler could stay on an EL 4 server. This would also mean you would >> have the option of installing Cobbler on a seperate box from >> cobbler-web, which is now /not/ supported easily by the RPM. >> >> > > The biggest issue I have seen with frameworks is you have to outline > that you are only going to use WebPlatform-X.Y and stick with that for > a while. This means that people using it will have to know that any > other apps they have on that server are going to use WebPlatform-X.Y > and not X.Z or W.Y. This becomes a bigger issue with voltronic > software because if Red-Lion uses X.Y and Blue-Lion uses X.Z then they > will never be able to summon Super-Massive-Sword. >
Our interconnects here remain language-agnostic... XMLRPC. I'm also not sure coexistance of one or more lightweight web stacks on the same box are a problem, as we wouldn't be talking about app servers (or even databases) at this point. > And with a lot of web-plats you end up bundling your own version > inside of you app to get around where you needed X.Y but the mainline > has bundled Y.Y or W.Y. > We'd use whatever was in the distribution. I am very firm on not repeating the mistakes of J2EE culture. > One of the other issues I have seen with multi-language projects is > the constant context switching needed because language A and B are > different enough that you aren't sure if you mean an Object when you > meant an Entity etc etc. > Potentially. Right now the number of people contributing to the webapp compared to the core of Cobbler are very small. > These aren't impossible issues, but they are always better to say up > front and figure out how to best manage them versus finding out that > you ahve to completely rip out WebPlatform-X because it just makes > your skin itch any time you deal with it. > Right now we don't have much of a web platform at all... we have just enough to use template files for our HTTP pages. I'd like to be able to take advantage of other things, such as AJAX integration. The other rationale is that ovirt is already a rails app, so being able to reuse some of the cobbler configuration screens in ovirt may be an interesting concept. I have not yet discussed this with the ovirt guys, but it seems like it may be promising. That all being said, it's not a done deal -- which is the reason I sent the email out. My foremost concern is if we've got a Cobbler user reliant on the web app that has, for some reason, all EL 4 servers and nothing else. The second concern I have is the simplicity of the upgrade/installation process. It has to be just as easy as before with nothing breaking. So far, I think that's achievable and there could be distinct advantages from having a smarter MVC framework, as long as we keep things working over standard interconnects, like we are doing with XMLRPC now (and will continue to use) Anyway, something to think about... > >> For those concerned about setup, this would /not/ require a database as >> it would be using Cobbler for the model. (* = Daryl should be sending >> an email about this shortly, and we're going to put some Wiki examples >> up). Also this would move CobblerWeb to a seperately installable >> package, such as cobbler-web, reducing Cobbler dependencies for those >> that do not need the web app -- which seems to be goodness. >> >> Just thinking about it at this point, comments welcome. >> >> Django/TurboGears are also valid choices, but I figured since we already >> have the XMLRPC wrapper module we should use it. >> >> If we do this, the existing CobblerWeb code would continue to be >> included for a couple of releases as a deprecated feature before we >> would remove it. >> >> --Michael >> _______________________________________________ >> cobbler mailing list >> [email protected] >> https://fedorahosted.org/mailman/listinfo/cobbler >> >> > > > > _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
