Thanks for checking it out.. > I'm very much a wiki newbie, so some of my meta-issues may > just be being uninformed about wikiness. > > First of all, is it reasonable to submit comments on wiki > content here, or is there some way that I missed in the wiki > interface?
I'm pretty new to wikis with a wide audience as well; I'd expect that people's discretion at this point is sufficient wrt commenting in the wiki vs initiating a discussion on the mailing lists first. My sense is that if you have a fairly specific/well-defined comment, the wiki's probably a good place, but if you expect some discussion to occur, the mailing list is a better place to start, with the expectation that comments will be added based on the content of the mail discussion. > > I noticed that sidebar text (TBD, REVIEW, etc.) is not > wrapping in my browser (Firefox 0.9.3), even in the printable > view. I also noticed that the top of each page that contains > the top-level links and icons is slightly scrozzled, with the > icons displaying over some of the text links. Not sure there's anything we can do about that; I'm just using the MoinMoin wiki syntax for code. Probably has to do with the HTML that MoinMoin is generating. > > In section 1.2, "Declaring Controls Usage", it refers to the > acronyms "PI" and "CB". I don't know what those are. You > should make it clear what those are. No problem, I'll fix that -- it's short for "public interface" and "control bean". > Also in this section, the TBD asks how this will work for > non-Java clients. At what level is Beehive supposed to be > usable by non-Java clients? How can it possibly be more than > an RMI/IIOP interface? Yeah, this wasn't too clear now that I think about it. By "non-Java clients", I meant clients that have an affinity to Java, but aren't "plain old java code" -- JSP or BPEL-J. For example, if a JSP uses a control via a tag-lib, how is that relationship surfaced? > Section 1.3, "The Controls Client Manifest", really has a bad > smell to me. It really seems odd to generate a non-editable > properties file. Let's drill into this a bit more. Is it the non-editable part, the properties file part, or the combination that causes it to smell for you? Let's say everything else stayed the same but the file was XML.. The file is meant to be a manifest -- it's the result of introspection on the code. Saying it's "non-editable" is meant to say 1) there should be no reason to edit it 2) editing it could cause its contents to be out of sync with the code it was generateed from. Would it help if the file had the properties syntax, but was named ".mf" or ".manifest" ? > Nevertheless, in this file, and in the "Implementation Binding" > properties file, I think it might be worthwhile to make the > syntax a little clearer. When you have a properties file > syntax where the keys "look like" the values, where in this > case they both are class names, it would be worthwhile to > make the "key" and/or "value" syntax use a prefix to > differentiate it from the value syntax. For instance, using > a prefix like "bean." and "impl." for the "key" and "value" > syntax, respectively. The main issue I have with this is that I'm not convinced the value-add in self-documentation overcomes the need to parse the names/values to strip out this stuff (both in the minds of people reading, and in code). How about generating comments into the file that document its syntax?
