[RFC] SRS Section 2
jhuntwork at linuxfromscratch.org
Wed Feb 2 10:07:38 PST 2005
James Robertson wrote:
> I think having the client be able to parse the profile and do a
> validation of it in the same form that xmllint does today is what I am
> thinking. This is just for sanity checks more than anything. Having
> the client be able to edit profile files would be a really nice add to
> go with this functionality. If we stick with a traditional DTD, then we
> get same as xmllint gives us today. If we go with a schema based
> design, I think we get more options. We do need to decide the path
> forward. Either way, I want us to stick to the current DTD's
> functionality with the adds we have already talked about. I am not
> interested is other profile formats like the ALFS Simple Syntax or other
I don't think client(ui) should do validation, let that function be
built into the server(daemon), and make the client as dumb as possible.
Remember, the ui and daemon may very well be running on the same
machine, not necessarily across the network. And if you are running
across the network, you need to be able to speak to the daemon/server
anyway, otherwise you won't be able to do anything. The client can
'ask' the server to validate it and view the results. No need to build
that extra step into a client that we want to make as simple as we can
for porting purposes.
> Now I know we cannot fix every possible problem, especially some of the
> "configure" script type checks because each server may implement the
> commands differently as Gerard mentioned. This is correct, but I would
> at least like to know that I have checked a profile against the DTD to
> at least know it is sane and that I did not miss something stupid.
Right. But again, as there inherently needs to be communication to and
from the daemon to do anything, let the daemon handle all the *real* work.
More information about the alfs-discuss