I'll be done with the SSI rewrite tomorrow. I'd like to get the community's advice on a number of issues:
1-I changed the names of the files from Ssi... to SSI... This seems to be more consistent with the naming scheme of other files, and made things easier for me since I did a gradual rewrite of everything. This will make it harder to see what I changed when I submit a diff, however. I changed 75% of everything, so I'm not sure this matters. Is it ok? 2-What's the story with the SSI jar having the .renametojar extension? I'm surmising that this is because this class will be loaded under the system class loader rather than the user servlet class loader, causing the #exec functionality to be a security risk. Can't we just have a directory where we put servlets that should be loaded under the 'safe' class loader? 3-Right now the SSIServlet has an initialization parameter to determine whether unsupported commands ( #foobar ) should be ignored. It seems like the issue should be more complicated than this. There is a difference between #foobar and #if. #foobar is not supported by anyone, and should be handled the same way apache would do it ( echo an error ). #if however, IS handled by apache, and is not handled by the SSIServlet. Therefore it seems that the initialization parameter mentioned should only apply to the latter case. Personally I think this initialization parameter should be axed completely, as I don't see where its use solves more problems that it creates. For example, if a person did have code that used #if, #else, etc., then by ignoring these directives we'd end up making the output be even weirder ( and with no explanation of why! ) than if we just stuck [an error occurred while processing this directive] all over the place. 4-Right now we are not logging invalid atribute names ( --#echo nonExistantAttribute="foobar" -- ), or logging invalid commands, or logging invalid settings for attributes ( --#echo encoding="noSuchEncoding" var="DOCUMENT_NAME" -- ). Apache logs this stuff, it seems like we should too. Where do I log it to ( what classes/methods do I use )? Should there be a way to turn this logging off? 5-The command <#echo var='SOMETHING'> is not too useful right now, because what SOMETHING can be is highly constrained. I'd like to make so that this command searches the request attributes ( for a variable named SOMETHING ). This will make this servlet more useful when writing filters that use it. More importantly, it lets existing users who are using SSI already have more power without needing to rewrite their .shtml files in .jsp. [The company that I consult for said they would find this useful, so I'm not making this up] I'd like to also implement the #set command, so that it sets a variable in the request. Anyone have objections to this? 6-This servlet has the option of being buffered or unbuffered. Can someone explain to me why this is useful? The SSIServlet should never throw an error, so I don't see why this would matter. Thanks, Dan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
