(note: i've cc'd the libservlet-devel list, cos this discussion more properly belongs there. if you're interested, i suggest subscribing to that list at http://lists.sourceforge.net/lists/listinfo/libservlet-devel. thanks!)
prompted by stephen adkins' message about converting java apis to perl, i ask that people who have experience with both the java servlet api and perl to comment on the conversion of the servlet api to perl. some notes on mechanics can be found at http://libservlet.sourceforge.net/conversion_details.html. you can view the libservlet source online at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libservlet/libservlet/, or you can use anonymous cvs to check it out and view it locally. i/o is the biggest issue i think. in some ways IO::Handle is a great substitute for InputStream/OutputStream, but in this context it's kind of a pain. you really want to specify as few methods as possible in the interface so that servlet container implementors aren't forced into a corner with their implementation. when writing container i/o classes, developers should not have to override every IO::Handle method in order to achieve the right behavior. on the other hand, i want the libservlet i/o interfaces to be as naturally perlish as possible. so probably the compromise will be to specify ServletInputStream and ServletOutputStream interfaces as subsets of IO::Handle functionality. then implementors can provide their own implementations of some methods and delegate to IO::Handle for others. in re character encodings and conversions, my current plan is to write an IO::CharHandle class that takes the name of a character encoding as an argument and transparently performs conversions. the goal is to work with utf8 data only inside the boundaries of the container, and convert to native encodings when data passes out of the container. given that approach, i'm not sure what the scope of locale support reduces to. i'll definitely want a simple high level api (obtain a locale object for the current locale and pass it to other objects that have locale-specific behavior). the question is how much of the locale support in perl's core can be used and how that is affected by data always being in utf8 inside the container. finally, given the current state of threads in perl, i think it's safe to ignore them for now.
