Re: Starting point...
Thanks! Well, not a book covering this precisely, but maybe something covering servlets in the large. Just wondernig if there was one that was better than others :) Regards, Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting point...
Okay, I'm going to just state a few things just to make sure evertying gels in my head :) So basically (from the Servlet end), a JspServlet is initialized, this creates a RuntimeContext. Then, when the service is invoked it looks for some JspServletWrapper already associated with this .jsp in this context. If none exist, it creates JspServletWrapper which is a less servlet-styled Jsp compiler. This wrapper then contains a CompileContext, which presumably does the grunt-work of parsing and compiling the .jsp? Is there a simple explanation for the responsibilities of the two contexts mentioned (Runtime and Compile)? Oh, on a loosely related note: are there any good books related to this material, that would also just be a good book to have on the shelf? Thanks! Regards, Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting point...
That's true, out of date docmentation is practically useless. I would hope that if it were a complete enough document that hopefully design changes could be recorded in there as well (by whomever commits or creates the patch?). At least that'd be my hope, not to say that would actually happen :). If a single person has to maintain the documentation then they effectively have to digest and realize what various changes mean, so it makes sense that the person who makes the changes also change the design document. At least this way it possibly reduces some duplicated effort. Probably a silly question, but the JspC is the command line entry-point, and the JspServlet is the on-demand entry-point correct? Regards, Scott On 6/20/05, Yoav Shapira <[EMAIL PROTECTED]> wrote: > Hi, > You're right, that'd be a good thing to have, as long as someone maintains > it current. I personally don't have an overview, but I'd like to point out > one thing: it's important to keep in mind the two significantly different > use-cases of online (on-demand, in a live server instance) compilation > versus offline (typically command-line) compilation. > > Yoav Shapira > System Design and Management Fellow > MIT Sloan School of Management / School of Engineering > Cambridge, MA USA > [EMAIL PROTECTED] / [EMAIL PROTECTED] > > > -Original Message- > > From: Scott West [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 20, 2005 12:44 PM > > To: tomcat-dev@jakarta.apache.org > > Subject: Starting point... > > > > Hello all, > > > > I applied for one of the google coding awards, and I was thinking that > > to get started, I could start trying to document the design of the > > compiler. I still have no idea if I have the job or not, but I figure > > this wouldn't be a fruitless task in either case. So anyway, I was > > just wondering if anyone had a short overview of the design they'd be > > willing to share to get me started. Currently I'm just sort of pouring > > over the code and going at it that way, but if anyone has any > > suggestions or starting points, that'd be great! > > > > Regards, > > Scott > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Starting point...
Hello all, I applied for one of the google coding awards, and I was thinking that to get started, I could start trying to document the design of the compiler. I still have no idea if I have the job or not, but I figure this wouldn't be a fruitless task in either case. So anyway, I was just wondering if anyone had a short overview of the design they'd be willing to share to get me started. Currently I'm just sort of pouring over the code and going at it that way, but if anyone has any suggestions or starting points, that'd be great! Regards, Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ideas for optimization (Jasper)
Hello all, I'm a student, and I'm taking a very belated stab at the summer of code. Actually, I already submitted one proposal, but I really didn't understand what was expected (apparently google filters the proposals, then they go to the mentoring organizations?). Regardless, I figured better late than never, so: what do you feel would be beneficial to the Jasper compiler? I've done a little work with languages in the past, making a primitive lexer,parser,interpretter in Java and Haskell. Since the general direction of this is to optimize the compilation process, I was wondernig where people feel it tends to drag? Or I guess more importantly, is it even *known* where it could use some improvement? I read the post on bugzilla, and I would like to use that as a starting point. I know that I'd like to include documentation as part of the proposal, so that there is an overall design document. I feel this would be a great way to encourage more people, who are still unfamiliar with the design (as I am), to extend and improve Jasper. The one thing that usually stops me from really wanting get involved in a large project is the initial inertia that must be overcome before you can start. It'd be wonderful to reduce this by giving people a really good overview (read: design document) of what is currently present. Then as people add they can update the design to reflect the changes. Also, if there are any suggestions you have for the proposal, things you feel would make it better, don't be afraid to mention it. Please... please... mention it ;). Regards, Scott West - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
