Hi Wesley,
I'd propose to do it in some steps:
1. add the table (doesn't hurt)
2. prepare routines for reading/writing values from/to database (given opkg,
context)
3. prepare a routine to parse the configurator.values and feed the database
with them (doesn't hurt, yet, as it leaves the old thing in place)
4. work on the XML part:
- can you build the configurator.html out of xmls?
- can we initialize the database with the XML values?
- ... lots of things I didn't think about ...
5. switch over all the routines reading the configurator.values xml to read
the database.
Steps 2,3,4 can be done in parallel and can be properly tested before
switching over. Step 4 seems to be your main focus, most of it is what you
wanted to do anyway. We can move along without seriously hurting the existing
system and you'd be doing what you had to do anyway. Of course we need to take
care that steps 1, 2, 3 proceed well.
There appear to be some natural "assignements" to the tasks, but we should
discuss this in a call, I guess...
Regards,
Erich
On Wednesday 14 June 2006 17:28, Wesley Bland wrote:
> So this approach sounds good to me, but there are a few things that I want to
> know before I dive into this thing simply because I don't have enough time
> here this summer to be able to address all these issues:
>
> Would this still work for the current GUI or are there going to be some major
> changes necessary to continue the current method of running things? Would we
> need to keep 2 versions of things for a while to get things running? Also,
> how would the database values get seeded in the database? I'm assuming that
> DongInn is creating the table where these things will go. They could be read
> in from files so that we would have a setup with a configurator.sql to
> initialize the values and configurator.xml to show the display formatting.
>
> Lastly, and I don't want to sound pressing again, is this something that
> would
> happen soon (as in the next couple of weeks) or take a while? I'd be happy
> to do the XML part of this but if noone else has time to get the database
> part done, I'm going to be hurting when it comes down to crunch time.
>
> Thanks again for your patience,
> Wesley
>
>
> On Wednesday 14 June 2006 10:19 am, Erich Focht wrote:
> > All the applications need for configuration are the variables, maybe the
> > context. So the minimalistic approach is:
> >
> > Table : Configurator
> > Fields : opkg, name, value, context
> >
> > "context" is reserved for per-image configuration, for example.
> >
> > So:
> > opkg=ganglia
> > name=gmond_port
> > value=8649
> > context="global" (or "" empty string)
> > would be a valid entry for one variable of the global ganglia
> > configuration.
> >
> > context="image:myimage"
> > would specify that the configuration variable is valid only for the image
> > myimage, but not globally.
> >
> > This allows us to access the configuration variables easilly, even from the
> > client nodes or from chroot inside an image. Reconfiguring something will
> > be easier and backing up the configuration will also be much easier (as all
> > relevant info lives in the OSCAR database).
> >
> > The method how we get these variables into the database, how they are
> > displayed, in which form (html? anything else?) they are collected, should
> > be unrelated to the way the variables are stored. Actually the variable
> > collection method should be decoupled from its storage.
> >
> > So why not describe the collection method in an html or xml file? With the
> > current configurator.html files this would already work fine (I know this
> > is a problem for CLI) and be a pretty limited effort. If you can move one
> > step up and describe the input forms in XML, why not? The XML file can
> > state that a variable will be collected by clicking a radio-button or
> > selecting something from a pop-up menu, in the end the variable will have
> > exactly one value and this is what we'd like to find in ODA.
> >
> > So I'm an adept of what you call hybrid method. It is because an XML file
> > can later be easilly integrated into a web gui, but no matter how fancy you
> > make the GUI, it will not change the way how the variables are stored in
> > the database.
> >
> > Best regards,
> > Erich
>
_______________________________________________
Oscar-devel mailing list
Oscar-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oscar-devel
