February 2011 - web-devel

Rich Internet Applications using Haskell
by Bardur Arantsson 10 Feb '11

10 Feb '11

Hi all, I just though I'd let y'all know that I've started work on "Dingo", a small framework for creating Rich Internet Applications (RIA) in Haskell. The basic idea is that you write Haskell code and the framework generates all the browser-related bits you need (HTML, JS, state serialization, etc.) at runtime. Writing an application is centered around Widgets and Events which are just what you'd expect if you were writing a Gtk+/Swing/SWT/Qt application. The way the application starts is that you provide a "start the application" callback to a "runServer" function. When a client connects to the server the first time, the "main" callback gets run and can set up the main application widget however it wants. There's a basic example in Main (see attachment). It doesn't really do much interesting, but it does demonstrate that state transfer and updates (client->server and server->client) work and that events work at a basic level. I've attached a tarball of my not-even-close-to-pre-alpha code -- I won't bother putting this on Hackage since it's not actually useful for any real work yet. To get something working in a browser ASAP I've taken some... uhm, liberties with code quality, so I will not be held responsible for self-induced eye-gouging as a result of looking at the code. The current status is basically: * Uses Happstack-server for serving HTTP. Given Dingo's extremely simple serving needs it may be a bit of a "heavy" dependency, but it works for now and it's not really a high priority to change this. It's also definitely NOT eye-gouging-inducing, so that's a plus :). * Only very simple widgets are included: A "panel" container widget (corresponds to an unstyled <div/> currently) and "input", "select" and "button" elements (corresponding to their HTML counterparts). The idea is that Panel will be expanded to a more general container which can lay out subwidgets horizontally or vertically. * ALL mutable widget state is transferred to/from the browser for every callback. This isn't an issue with the simple example in Main.hs, but it might become an issue for larger widget hierarchies. * Only ONE client supported at a time. You read that right. Weird things will happen if you try to connect multiple clients. Immediate plans: * Find a better way to handle state transfer to lessen the burden of having to write JSON <-> JS and JSON <-> server-state translations by hand. I'm thinking that some of the ideas from the "Invertible Syntax" paper ( http://www.informatik.uni-marburg.de/~rendel/unparse/rendel10invertible.pdf ) may apply for this. Text.JSON.Generic may also be workable, but I had some trouble getting it to work with Text values and it doesn't help with generating the widget-specific JavaScript. * On a related note, I need a better way of generating JavaScript than string concatenation. Unfortunately, HJScript seems to be *too* strict about typing. * Expand the selection of widgets with more complex widgets so that I can get a feel for how the current Widget type class may need to be generalized/tweaked. Something requiring CSS would be good too, so I can hopefully get a basic theming mechanism down. * Get rid of the "one client only" limitation so that Dingo may actually become somewhat useful in practice. * A way of tracking client-side and server-side updates so that only things that have actually changed are transferred between client and server. For the server side this should be easy enough and for the client I'm thinking of something like attaching a "change()" event handler to all relevant DOM elements. Comments and suggestions appreciated. Cheers,

2 2

Re: [web-devel] [Haskell-cafe] http-enumerator: redirects, streaming and keep-alive
by Felipe Almeida Lessa 07 Feb '11

07 Feb '11

On Wed, Feb 2, 2011 at 6:30 PM, Antoine Latter <aslatter(a)gmail.com> wrote: > Or you could remove the socket from the map while it's in use. And what about connection limits? We shouldn't create a thousand connections to the same host =). -- Felipe.

2 1

big executables in Yesod 0.7
by Dmitry Olshansky 07 Feb '11

07 Feb '11

Hi, I tried Yesod 0.7 (congratulations with new release!) and found that executables are too big. The reason is yesod -> wai-handler-devel -> hint dependency. In production it is not needed probably. Could it be refactored later in some way? Best regards, Dima

2 1

http-enumerator decisions
by Michael Snoyman 07 Feb '11

07 Feb '11

Hi everyone, I'm starting to make plans for http-enumerator 0.4, which will include keep-alive support, proper streaming request bodies and *hopefully* user controlled certificate checking. I say hopefully because that really depends on being able to stop using the OpenSSL backend. I know that I'm personally using it in my production systems because one of its dependencies, the AES package, does not compile on 32-bit systems. My question is, does anyone have other reasons for using the OpenSSL backend which should stop me from making such a transition? Thanks, Michael

1 0

ALPHA: http-types 0.1
by Aristid Breitkreuz 06 Feb '11

06 Feb '11

Hi, I just wanted to announce that I uploaded a first version of http-types to hackage: http://hackage.haskell.org/package/http-types-0.1 This version is very much an Alpha version. And, uh, do give feedback: I promise that I will keep myself better in check, this time. Aristid

3 13

multiple user interface languages
by Alberto G. Corona 04 Feb '11

04 Feb '11

Are there any high level, efficient, transparent way to handle multilanguage appkications? (I mean UI languages, that is languages that people use to communicate) There are many "dirty" ways to handle it . But none are satisfactory. Either to.. 1) Store the string in a database and perform inefficient queries to compose the page (optionally with caching). The user interface code is not particulary elegant. 2) Store the string and string constants in a separate module for each language. It is as efficient at it can be. but not particularly elegant. 3) Create multiple pages, one fo each language It is.fast at rumtime, but at the cost of duplication of the embedded code, o it is not very maintainable. Time ago i used the option 2 for my first Haskell web application, So every page had at the botton a runtime asignation of the language strings used in the page: (yesvar, novar)=case lang of "es" -> (LangEs.yes, LangEs.no) _ -> (LangEn.yes, LangEn.no) For yes/no strings I don´t like it. Any other alternative?

1 0

Timing WAI response generation
by Neil Mitchell 04 Feb '11

04 Feb '11

Hi, I've ported Hoogle to WAI/Warp and it's great - I am very happy. The only feature I lost is the ability to time how long a response takes to generate/send. For my purposes, I'm not even overly bothered whether it's the time taken to generate, or the time taken to send to the clients machine, or something somewhere between these two times. I came up with a couple of ideas: 1) I generate my response with a lazy byte string. I could make the final chunk of the lazy bytestring something impure (with unsafePerformIO) that writes into an MVar when it gets forced. 2) If I knew more about enumerators/iteratees I think it might be possible for each chunk generated to start a time, wait til the chunk is ready, and then stop the timer - giving the exact time to generate all the chunks. Or append two chunks, one at each end, that start/stop the timer. Does anyone have any better suggestions, or ways of performing the timing? Thanks, Neil

2 1

Re: [web-devel] ALPHA: http-types 0.1
by Aristid Breitkreuz 04 Feb '11

04 Feb '11

Writing this from my phone, so I'll be brief. I'm OK with the name CIByteString, I just thought the Http would clarify that this is not safe for different encodings. But I can change this. Parsing/rendering sounds like a good idea. I will probably use different function names, but you can set up aliases in wai-extra, right? Headers are already there, no? You're confusing me. Thanks for the nice feedback! Aristid "sent from my Android" Am 04.02.2011 07:09 schrieb "Michael Snoyman" <michael(a)snoyman.com>: Alright, everything seems fine to me. Some more comments: * Besides the fact that I think HttpCIByteString is too verbose, it presents another problem: I cannot transparently switch over to it in WAI and http-enumerator. If you kept the same name (CIByteString), I could simply switch over to your version without any breaking changes. * I like methodGet et al. * Do you want to consider some parsing functions? I can provide you the code. Some things I would imagine would be: * parseQueryString :: ByteString -> [(ByteString, Maybe ByteString)] (I'm not sure if in practice anyone cares about the Maybe btw, but you are right that it is more theoretically correct) * renderQueryString :: [(ByteString, Maybe ByteString)] -> ByteString * parsePath :: ByteString -> [String], which would do all splitting-on-slash, percent decoding and UTF-8 decoding * renderPath :: [String] -> ByteString, which would be the reverse of parsePath * renderPathQuery :: [String] -> [(ByteString, ByteString)] -> ByteString * parseHttpAccept :: ByteString -> [ByteString] * Are you planning on adding headers as well? Basically, feel free to raid Network.Wai.Parse[1]. [1] http://hackage.haskell.org/packages/archive/wai-extra/0.3.1/doc/html/Networ… On Fri, Feb 4, 2011 at 12:23 AM, Aristid Breitkreuz <aristidb(a)googlemail.com> wrote: > OK, I uploaded a fixed version: > http://hackage.haskell.org/pack...

2 3

Re: [web-devel] Proposal: http-types
by Michael Snoyman 04 Feb '11

04 Feb '11

2011/2/3 kyra <kyrab(a)mail.ru>: > On 2/2/2011 1:32 PM, Michael Snoyman wrote: >> >> * Request/response header key. In WAI, I use data CIByteString = >> CIByteString !ByteString !ByteString, one version being the lowercase, >> the other the original. > > I'm using Microsoft kernel-mode http server (http.sys). They have "known > headers" enumeration and "unknown headers" string. Now, while http.sys > parses requests and gives me enum keys for "known headers" I have to unparse > them back strings to adapt them to WAI. It's not too much critical, but I > would prefer the header key to be an ADT. > > Cheers, Kyra. > Do you mean you're implementing a WAI handler on top of http.sys? That's cool, would you consider releasing it on Hackage? I think the header key especially would be a bad fit for an ADT: there are *far* too many standard ones to really include all of them, and much more than request methods, new ones are made up. Just look at all the special handling in http-types for the request methods, and imagine writing those extra lines for *every* supported header. Michael

1 0

[Yesod] how to write PersistFIeld instance?
by Katsutoshi Itoh 03 Feb '11

03 Feb '11

I'd like to introduce serializable data type like this: data Role = Teacher | Student deriving (Read, Show, Eq, Ord) share2 mkPersist (mkMigrate "migrateAll") [$persist| User ident String : : role Role Maybe Update : |] instance PersistField Role where ??? Would you teach me how to write this instance?

3 3