I'm not sure where it should reside to be honest. I can see argument for both sides. If I wanted to access data that resides on an IIS machine that has challenge/response turned on, it would be good to have cookie/auth support in jstl <c:import> but one could easily argue it should be in a bean to provide more advanced capabilities like caching or other RPC protocols.
For an enterprise solution with high loads, it might make more sense to create a custom solution, but I've seen situations where data comes from third parties. Trying to get data providers to build a custom RPC mechanism often is more trouble than it's worth, so a simple <c:import> mechanism that supports cookies & authentication would be a simpler solution. I'm glad the decision isn't up to me because either way you go, some one is going to complain. peter Shawn Bayern wrote: > > On Wed, 21 Aug 2002, peter lin wrote: > > > in the interest of discussion. I find it useful to have cookie, > > user-agent and other advanced capabilities in a web services context. > > As web services becomes more common place, supporting those features > > might become very important. > > But is it important to support this from within JSP pages, instead of > Java-based components? > > -- > Shawn Bayern > "JSTL in Action" http://www.jstlbook.com > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
