23:17:31 <stepkut> hmm, do you think a directory listing of files, file size, and mod time, is a valid use of a table
23:20:28 <McManiaC> its a list of items, isnt it? :)
23:20:51 <stepkut> well, if it was a list, then I would just use a list
23:21:03 <McManiaC> well... a table
23:21:04 <McManiaC> not just a list
23:21:09 <stepkut> yeah
23:21:12 <stepkut> I think it is valid
23:21:47 <stepkut> I am trying to documenting the FileServe module.. but I can not very well right in the documentation, "the file serving module does not support directory listing" now can I ?
23:22:02 <stepkut> s/right/write/
23:24:04 <McManiaC> sure, why not?
23:24:32 <McManiaC> 16 files changed, 890 insertions(+), 411 deletions(-)
23:24:45 <McManiaC> "I just take a quick look here, won't do too much today"
23:24:46 <McManiaC> :>
23:24:54 <stepkut> :>
23:25:02 <stepkut> did you get everything working against head ?
23:25:07 <McManiaC> jup
23:25:19 <stepkut> but not the new auth ?
23:25:25 <McManiaC> not yet
23:25:43 <stepkut> that is definitely a big issue for happstack 7
23:25:58 <stepkut> here is a long, but useful way to do it
23:26:35 <stepkut> you could add an 'export/import' feature to you site that dumps the contents as XML, or something. Then you can just export from one version, and import to another. That is useful if you would like to have an export/import any
23:26:37 <stepkut> anyway
23:26:45 <McManiaC> and I even moved a few other components of my state, so I'll *have* to take a look at it one day
23:26:58 <stepkut> yeah
23:28:11 <McManiaC> stepkut: yeh, I thought about something like that
23:28:37 <McManiaC> would be a bit tricky/hacky tho to get stuff like "data Foo = Bar | Moep" into a XML file :)
23:29:30 <stepkut> depends how pretty you want it..
23:29:38 <stepkut> happstack-data can actually auto-generate XML
23:29:48 <McManiaC> from a state?
23:29:57 <stepkut> yeah
23:30:02 <stepkut> I think you just need Serialize instances
23:30:11 <McManiaC> coolio
23:30:19 <stepkut> though the XML stuff is a tiny bit gutted in 6 because we wanted to drop HaXml for a while
23:30:34 <stepkut> but it is mostly still there
23:32:58 <McManiaC> could I do somethinge like writing an export function ("state -> xml"), change Happstack.Auth into Happstack.Auth.Internal.... and import it back again ("xml -> state")?
23:33:59 <stepkut> that is what I am suggesting. The XML might still have the same issue with the rename problem. But you could easily modify the XML unlike the binary.
23:34:39 <stepkut> it's still not trivial, but it might be an easy work around in the meantime
23:35:20 <McManiaC> ok
23:38:33 <Entroacceptor> stepkut: but make directory listing optional
23:39:15 <stepkut> Entroacceptor: of course
23:39:34 <Entroacceptor> and I guess most won't use it, anyway
23:40:53 <stepkut> Entroacceptor: the are a few options: 1. no listing, can only request exact files. 2. no listing, but will show index.html files 3. show index.html files if present, otherwise show listing. 4. show listing even if index.html is present
23:41:13 <stepkut> you will also be able to supply your only listing generation function
23:41:36 <stepkut> that way you could do fun things like have it show image thumbnails, or whatever else you want
23:42:23 <Entroacceptor> yes
23:42:39 <Entroacceptor> but that would go a bit over what happstack's focus is atm, doesn't it?
23:42:49 <stepkut> one question is what to do about the current fileServe API. The 'obvious' behaviour change would be to make it work like #3.
23:43:07 <stepkut> but if I change the API then I can make it easier to pick which of the 4 options you want.
23:43:12 <Entroacceptor> add fileServerWithIndex
23:43:27 <stepkut> there are too many fileServe functions already I think..
23:44:12 <Entroacceptor> then maybe make a new module
23:44:15 <stepkut> writing the thumbnail directory viewer would go a bit over happstacks focus. But, parameterizing the file serve code so that users can write a viewer fits nicely.
23:44:40 <Entroacceptor> and then abstract the directory reading
23:44:53 <Entroacceptor> so you can use git repos :)
23:44:58 <stepkut> :-/
23:45:07 <Entroacceptor> (that's what I'm thinking about with my project atm *G*)
23:45:13 <stepkut> I think that might be bending it a bit too far
23:45:25 <stepkut> though it sounds neat
23:45:38 <stepkut> if it could be done neatly, I would certain take a patch :p
23:46:04 <Entroacceptor> (or get stuff from databases)
23:46:09 <Entroacceptor> mhm
23:46:09 <stepkut> here is what I think I may do.. I will leave the behavior of fileServe unchanged
23:46:25 <Entroacceptor> that could change the url parsing to a more object-like tree
23:46:27 <stepkut> because fileServe is a confusing name anyway. We have serveFile and fileServe
23:46:40 <stepkut> instead, maybe we should have, serveFile and serveDirectory ?
23:46:51 <Entroacceptor> serveFile does what again?
23:46:56 <stepkut> and serveDirectory can have the better API. And fileServe will eventually be deprecated.
23:47:03 <Entroacceptor> sounds good
23:47:34 <stepkut> serveFile serves a specific file from the disk. like, serveFile (asContentType "text/plain") "/etc/motd"
23:47:47 <stepkut> the usefulness is that the name of the file that is being served does not come from the URI
23:48:18 <stepkut> so you could do: simpleHTTP nullConf $ dir "message-of-the-day" $ serveFile (asContentType "text/plain") "/etc/motd"
23:48:19 <stepkut> for example
23:48:25 <Entroacceptor> yes
23:48:39 <Entroacceptor> you could rename that to filePasstrough or so...
23:48:53 <Entroacceptor> but if there's serveFile and serveDirectory, it would be good(tm)
23:48:59 <stepkut> yeah
23:50:49 <stepkut> those will be the two main file serving functions. And there (perhaps in a different module) there will be some lower-level function that let you build your own custom server out of building blocks. Using that build-a-server stuff is how you can change things like using a custom thumbnail generator, or using a different way of calculating mime-types, etc.
23:51:07 <stepkut> but if you don't need that type of power, you just use one of those two functions.
23:51:52 <stepkut> it is already setup like that now. But it just needs a little more flexibility, refactoring into modules, and documentation
23:52:09 <stepkut> gotta run, time for dinner party soon
23:53:10 <Entroacceptor> hf
23:55:41 <Entroacceptor> stepkut: one thing reading the new crash course section about cookies: I don't like the links on "search for cookie security issues"; expected is a page with an overview or so; I know how to use the search engine of my choice... these links feel a bit weird.
23:55:56 <Entroacceptor> (obviously weird enough to message you about them *g*)
23:56:55 <stepkut> :)
23:57:18 <stepkut> I'll see what I can do
23:57:20 <Entroacceptor> and writing a web app without a great understanding of security risks is bad, anyway
23:57:25 <stepkut> sure
23:57:39 <stepkut> but first someone has to tell you that there are security risks :)
23:57:46 <Entroacceptor> yeah
23:58:07 <Entroacceptor> or maybe make some higher-level libs for storing session data that it becomes a non-issue
23:58:16 <stepkut> it would be nice to get some code in place to help with XSS, etc, attacks as well
23:58:24 <stepkut> yeah
23:58:30 <Entroacceptor> XSS is easy, just filter all output
23:58:42 <Entroacceptor> hstringtemplate can do that pretty easily ;)
23:59:37 <Entroacceptor> mhm