A file system / database API

[Jake Verbaten]

I've tried to think about how I would represent either a file system or a database as a Signal

The question of error handling and concurrency has come up a few times and I can't think about how this would be best represented.

I think writing a Signal based abstraction on top of either node's file system ( http://nodejs.org/api/fs.html ) or the levelDB database driver ( https://github.com/rvagg/node-levelup ) would be an interesting exercise.

The file system is interesting because it has to deal with the bullshit of resource allocation and references to file descriptors.

The levelDB driver is interesting because it's one of the simplist database APIs and if you remove the bullshit from IndexedDB you get levelDB which means we could have a Signal representation for persistence in browser based elm apps.

If anyone has any ideas for how to implement either I would love to talk about them!

[Dobes Vandermeer]

I think if you treat the database / filesystem like a web service, you can model the API in teh same way as web services are currently done; i.e. in the Flickr example:

http://elm-lang.org/edit/examples/Intermediate/Flickr.elm

Basically, when the query changes it fetches new data.  The "query" for files and databases might be different than for a remote URL, but whatever data structure it is will describe the desired input based on some other input.

For a stream of data (incremental parsing) you might have a signal that sends chunks of data "as they arrive" and the automaton could accumulate the parsed data into its state.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jake Verbaten]

Modelling a database after a req / res model seems like it's doable but unnecessary limiting.

The req / res model is limited because it forces sequential requests & responses. 

I really just want to make concurrent write and read requests. I want to open an arbitrary number of streaming read requests concurrently. As well as having an arbitrary number of write requests concurrently.

[Evan Czaplicki]

I think adding IDs in the style of buttons might do it for concurrency. I think this would be a lower-level way of doing things.

Also, I wonder if you could give the API a sequence of automatons to run? Each automaton could take some file stuff and result in a new action which asks the file system for something. Then the next automaton takes that file stuff and repeats. Then interactions with the file system can be specified without any talk about file descriptors, they can happen concurrently and at different rates, and this could probably be implemented on top of the ID-style interface.

Does that idea make sense at all?

[Jake Verbaten]

I don't quite get the idea.

It would be cool to draft an API for leveldb with

 - `thing.get(key)`

 - `thing.batchUpdate(changes)`

 - `thing.rangeQuery(start, end)`

If we can cover concurrent updates & reads as well as concurrent streaming reads that should cover all bases.

I like the idea of giving it a set of automatons but I can't imagine how that would work.

I want to prototype an API for this (in JS). The other concern of course is errors, all three of those operations can return either a result / void or an error.

Also the `rangeQuery()` will have a notion of end that we need to capture. Your current websocket API ( https://github.com/evancz/Elm/blob/dev/libraries/Native/Signal/WebSocket.js#L12 ) does not capture the notion of close.

The notion of close is very important to handle network disconnections for mobile apps.

[Simon Buist]

Hi there. 

Your FS/DB API interests me. While I am not making an API, I am however in the process of hacking in some persistence for my own personal project. I am doing it via ports and then just jamming in traditional storage the same way webapps do.

I am extending the Editor.hs and Generate.hs files as well as editor.js used in elm-lang.org to incorporate (consented!) keylogging and mouse (x,y) logging, which I wish to store on my server running a modified version of elm-lang.org

This is in order to gather user behaviours during participant studies. The project is my undergraduate dissertation on Human Computer Interaction. I am studying the usability of Elm over JavaScript for a given programming task with the motivating question: "Is FRP really easier than Imperative?"  (The paper is (a work in progress) here: http://spanners.github.io/dissertation)

[Jeff Smits]

I read your paper for as far as it is online. Sounds like a big, ambitious project. A tip for the structure of your dissertation: some papers with a user study have a dedicated "Treats to validity" section before the conclusion of the paper. I usually find that a nice structure as reader. Anyway, I don't know the requirements you have to meet; feel free to ignore this unsolicited advice ;)

I can't help you on the FS/DB part. And I suspect Jake didn't follow up on this challenge. There is someone else who looked into DB/FS access. But I would suggest that you use ports and hack the DB/FS part in JavaScript, I think that's faster.

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.