Felix Meschberger wrote > Please reconsider the use cases for the basic thing we want to build: A > processor taking request/response objects to be run (a) for regular HTTP > requests and (b) for batched/long-running/background/whatever requests > without a real HTTP request behind. > > For case (a) we have a HttpServletRequest/Response combo ready for use. > For case (b) we don't generally have one (or we have one to use as the > basis but not for direct use, because the objects will be unusable once > the real request has terminated). > > So we have to have functionality to (a) create > SlingHttpServletRequest/Response objects out of regular HTTP objects and > (b) create SlingHttpSeervletRequest/Response objects "out of nothing". > > For (a) we can of course reuse the real HTTP request/response objects > for (b) we can't. > > Thus by defining two simple builders to setup a > SlingHttpServeltRequest/Response object which is at the heart of all > Sling processing, we can handle both cases transparently without special > casing again. > Yes, I know - but...if we base just on the http servlet request/response we don't need a builder at all. Everything can be handled internally.
Now, I'm not agaist a builder completly but if we can avoid it, we have one service less and people are used to use http servlet request/response. Carsten -- Carsten Ziegeler [email protected]
