Re: Trying ARK feedback
Unknown <[email protected]>
| Newsgroups | gmane.comp.sysutils.ark.devel |
|---|---|
| Message-ID | <[email protected]> |
Harlan, replying to my cry for help (or something) wrote: > > Want to run (Sidai-style) ARK stuff on one host? OK, you > > gotta tell ARK about it; something like... > > Yes, 4 small pieces of info in 8 lines, surrounded by > hair. ... Yep. Welcome to XML :-( And, no, you're not the first to look on in horror. Using XML is one of the basic bets (of the current version) of ARK. We avoid inventing another language -- which we would probably do badly -- and we piggyback on something that actually fits the problem (ugliness aside), and that has some momentum/tools/etc. It is a closely-balanced decision. Paul Anderson's group at Edinburgh looked into the same abyss, and either went the other way or came very close to it. (The latest, Paul?) There may come a time when we'll have GUIs and pre-processors and whatnot to cover up the mess, but right now "speaking ARK" means doing that angle-bracket thing 'til the cows come home. No way around it. Similarly, the "ARK configuration language" behind those angle-brackets (you know, the "ARK2" thing -- things, fields, values, ...) is not going to change radically any time soon, until we have lived with it long enough to know what should replace it. And it *does* have limits (e.g. no nested fields), and I am sure we will be annoyed by it at times. (There are plenty of "extensions" we can think about, meanwhile, however -- e.g. constraints.) > For example, I don't see an obvious "roadmap" that tells > me what I need to do to get up and running. OK, I hope the docs are now a little better on this (with more to do). But the real issue is: ARK is a framework, not a tool. "Up and running" -- as *what*? ARK as a package manager? As a PIKT front-end? As an RPM front-end? As something to do a little user-management? We'll work with you (and anyone else) on any of those, or anything else that's cool that you want to try. (Chip-design, anyone?) > I see webpage/*.txt stuff that isn't really .txt files. Yes, this is a bug. They were .txt files when I started :-) Now they're HTML files that need a shell put 'round them. I will happily change them to another suffix if someone suggests a good one. Note: I expect the web stuff's gonna change a lot anyway... > ... I found an email message from Will that is starting to > walk me thru the steps to get this enabled in a production > environment and I'm still slogging thru it. I haven't > found "better" instructions, ... Is this something I failed to fold into the documentation? If so, could you forward a copy? > And there needs to be some way to easily maintain it, > which means the info needs to be "changed" in *1* place > only, and that info must be automatically propagated to > the places that need it. Heartily agree. Let's find the offenders and, if possible, shoot them. > And if we can come up with a clean/simple way to specify > the XML info, we should use it. Ideally, we should be > able to generate this file from the XML info, and then > "prove" the info by regenerating the XML info and > comparing it to the originals. Hey, I'm doubtful -- it's inventing a new configuration language (or several) -- but I'm not standing in anyone's way :-) > > I've spent about 10 minutes on the glasli1 hosts' structure > > over the life of the entire Arusha Project. ... > > You wrote it and understand how it works. ... Yes, I'm well aware I'm the worst person to comment on this stuff. > I'd really like to see "ark" be a script that is > self-bootstrapping. In other words, it could/should have > a way to make sure it can download, compile, and install > python, pyxml, ersh, and whatever else it needs to "get > going". This will also solve the "new host running a new > OS" problem. Very cool! -- I've added it to ARK/webpages/ideas.txt. Will