Stephen John Smoogen wrote:
On Mon, Sep 8, 2008 at 10:50 AM, Michael DeHaan
<mdehaan(a)redhat.com> 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
> cobbler(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/cobbler
>
>