The following is an email I sent to Danny Angus and the James PMC last Friday. I look forward to hearing responses to this plan.
On 7/8/05, Danny Angus <[EMAIL PROTECTED]> wrote: > Hi Anne, > > Can you confirm that your proposal has been accepted by Google Summer of Code? > > If so can you provide us with your plan, so that we can discuss your > involvement and our next steps. > > d. > > P.S. it might help communication if we know what timezones we're all > in, I am in BST/GMT. > Hi Danny, Yes, I can confirm that. Sorry about not getting to this sooner; I've had to clarify some tax/school information with Google before I was finally cleared. My plan: 1. Build the console first. The GUI, layout, etc elements, NOT the plugins and James-specific code. I'm working on this right now. The way I'm designing it is: Plugins, to display a page on the James console, will create a ConsolePage object. This ConsolePage object will then store various elements for display. For form elements, I created an interface called ConsoleQuestion that defines public String getQuestion, public String getHTML, and public String getDescription. Classes that implement ConsoleQuestion will store a question, then an answer field for the answer. The question will be returned via getQuestion, and the _HTML_ for the answer field will be returned via getHTML. This is important, as each class implementing ConsoleQuestion will be allowed to create its own way of answering that question. There will be classes such as ConsoleTextfield, ConsoleList, ConsoleTextarea, etc. getDescription will return a human-readable string describing what should be in the answer field. For example, a ConsoleQuestion class would return (strings can be changed by plugin) "Password:" for getQuestion, the HTML for a PASSWORD field for getHTML, and "Password must be a combination of letters and numbers" for getDescription. The console would (presumably) format the text of getDescription as small text under the input field. I also created a ConsoleText class to store raw text/HTML for direct display on the console, and a ConsoleMenuItem to represent a single menu choice (icon associated as well to the choice). So a plugin to the console could use any of the above classes (or derivatives) to build a page (adding various elements to a ConsolePage) for display to the user. A plugin will then send over the ConsolePage to a template JSP page to be written out for display. NOTE: 99% of the HTML code for the console will be written out in one or two JSP template pages, so the console L&F can be easily changed. Do not be confused by the presence of a function called getHTML: all it will do is write out VERY SPECIFIC HTML code for that particular class. For example, in my current iteration of ConsoleTextfield, getHTML returns only (INPUT TYPE=textfield size=some_size name=some_name value=default_text class=consoletextfield). The rest of the GUI still has a few details to be ironed out, but I don't believe there will be a problem. NOTE: Despite the fact that I say such things as "created" or "written already", nothing is set in stone. I merely wrote out a few classes such as ConsoleQuestion, ConsoleTextfield, ConsolePage, etc to see how things should work. I am not married to this approach, so nobody should consider it to be the final word. If anybody has input, I would welcome it. 2. Currently, I'm planning out a two-parter for the actual James/plugin code: Plugins and a communications overlay over James. First the plugins. In the architecture I'm thinking of, plugins will be added to the console and handle the grunt work, such as building pages for display to the user, processing form data, figuring out what the user wants, etc. These plugins will then communicate over XML-RPC (or some other protocol, again I'm not married to this choice) to the communications overlay on James. This overlay will handle the actual work, adding users, changing forwarding settings, editing config.xml, etc. This division of labor is an important distinction, as James and the console may be located on different machines, for example. In this case, James/ the communications layer will be located on one machine, and the console/plugins will be located on the second machine. Also, other people may choose not to use this console, and instead integrate James into their own console (for example, Plesk, CPanel). Other consoles can drop this project's console and communicate directly with the communications overlay on James. Plugins will implement a ConsolePlugin interface which will define two methods: public ConsolePage doMenu, public ConsolePage doForm. Links from menu options on the console would be processed by doMenu, while doForm will handle forms processing. Of course, doMenu would receive relevant data on which menu item was clicked, and same for doForm. The methods would return a ConsolePage object that describes what the next page should contain. As for timezones, I am in the US, Central Standard Time. Previous posts to this thread have involved icon discussion. I should note that I have acquired the permission of several artists to use their images in this project. Several have also noted that they would be honored to create some custom icons for us. If anyone wants, I can forward their permission emails to you/the mailing list. I'd like to hear what you think of this architecture, and any modifications/other archs that you think would work better. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]