On Tue, Sep 18, 2012 at 12:19:46PM -0500, Bill Stephenson wrote: > On Sep 15, 2012, at 10:58 AM, Mark Stosberg wrote: > > > Most web clients support JSON now, which allows for more complex > > structures than the simple key/value pair that CGI.pm uses. > > > Mark, I think this is relevant to what I'm advocating here. > > That JSON support is accomplished with javascript parsing a string of JSON > data that is stored in the localStorage key/value format. I think that's a > very clever use of the localStorage feature because it extends the > functionality without adding complexity. > > Here's an interesting article on that: > > https://hacks.mozilla.org/2012/03/there-is-no-simple-solution-for-local-storage/ > > That article points out the value of the simplicity in having the > localStorage function and the key/value format, and also how the IndexedDB > feature is not so simple. So, I'm not at all alone in seeing the benefits of > these simple to use functions and this format. That simplicity is really > quite ingenious, and I think this is what's important to keep in mind. > > What developers are doing with localStorage and JSON on the client side is > really not any different in concept than storing a string of JSON data with > CGI.pm's save function on the server side. I think that sounds pretty handy. > > Here's a quote from the author about that: > > "This local storage solution has a few very tempting features for web > developers: > > ? It is dead simple > ? It uses strings for storage instead of complex databases (and you can > store more complex data using JSON encoding) ..." > > In that article the author, Chris Heilmann, also discusses how unforeseen > uses of the localStorage feature have revealed issues with how it is > implemented. He offers several ideas on how to deal with those issues and he > concludes his findings with "We need to fix this". > > It seems to me that we are in a somewhat similar situation, but are leaning > towards a "We need to ditch this" conclusion. > > As I've said, my reasons for advocating for this feature are selfish. I am > not qualified to help implement it so how can they be anything but selfish? > But, that does not mean others will not also benefit. I think the example of > creative and clever usage discussed above helps to demonstrate that. > > While I may not be able to help implement the feature, I might be able to > help with example code and documentation, and I'd be more than willing to try. > > Kindest Regards,
It is unclear to me exactly what feature you're advocating, even though I went back and read the previous threads. I'd like to point out that while it doesn't matter what the client or the server do, the defacto standard is to send key/value pairs to the server no matter what the HTTP method is. CGI.pm will happly parse a k/v string sent via POST just as it would sent via GET; however, if you send just JSON to the server, you must manually parse whatever is in the POSTDATA field. That's my experience anyway. It'd be nice to have something on the server that recognized the JSON as natively as a k/v query string, particularly for non-GET methods. Also, YUI 3 has some interesting local storage options. Brett > > Bill > > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > > -- Register Now for cPanel Conference Oct 8-10, 2012, Houston, Texas http://conference.cpanel.net/ ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
