[plt-scheme] Questions about Web Server usage

From: Jay McCarthy (jay.mccarthy at gmail.com)
Date: Wed May 30 10:01:34 EDT 2007

Yes, this is likely what I will do.

Jay

On 5/30/07, Robby Findler <robby at cs.uchicago.edu> wrote:
> I think that probably a nice compromise would be to have a function
> that looks like a field selector, but does both a field extraction and
> a conversion from bytes to a string. It would be a contract on that
> function that the string can be converted.
>
> This would shift the blame properly and would keep people from having
> to have to find the right mzscheme library function.
>
> How does that sound?
>
> Robby
>
> On 5/29/07, YC <yinso.chen at gmail.com> wrote:
> >
> > On 5/29/07, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> > >
> > > > It's not that difficult: bytes->string/utf-8 and family.
> > >
> > > > The main problem is that if this is going to fail, I don't want to be
> > > > the one blaimed for it. The server has no reason to look at these
> > > > values, so it irks me that it crashes by them. Furthermore, by moving
> > > > the error in the servlet code, it can be caught more effectively and
> > > > displayed to the user in an appropriate context.
> >
> >
> > Perhaps an on-demand conversion can be the best of both worlds?  i.e. the
> > bindings are parsed as bytes, but bytes->string* is called with
> > extract-binding, so the error can be trapped by servlet, but we don't need
> > to write explicit conversions in servlet unless necessary (and might be
> > possible to pass in encoding too to switch between
> > utf-8/current-locale/latin-1).
> >
> > Just some more ideas...
> >
> > yinso
> >
> >
> >
> >
> >
> >
> >
> >
> > _________________________________________________
> >   For list-related administrative tasks:
> >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> >
> >
>


-- 
Jay McCarthy <jay.mccarthy at gmail.com>
http://jay.teammccarthy.org


Posted on the users mailing list.