00:00:06  <Raynos>Do you have a version of leveldown that works on 0.11 ?
00:33:45  * thl0joined
00:37:22  * st_lukequit (Remote host closed the connection)
00:38:25  * thl0quit (Remote host closed the connection)
00:39:00  * thl0joined
00:43:17  * thl0quit (Ping timeout: 252 seconds)
00:57:03  * dominictarrquit (Quit: dominictarr)
02:02:32  * thl0joined
02:45:21  * owen1quit (Ping timeout: 256 seconds)
02:51:46  * ramitosquit (Quit: Textual IRC Client: www.textualapp.com)
02:51:51  * timoxleyjoined
03:05:35  * owen1joined
03:19:18  * ralphtheninjaquit (Ping timeout: 264 seconds)
03:30:43  * dominictarrjoined
03:46:43  * thl0quit (Remote host closed the connection)
03:47:18  * thl0joined
03:51:33  * thl0quit (Ping timeout: 248 seconds)
03:53:17  <rvagg>Raynos: leveldown should compile ok up to 0.11.3
03:53:30  <rvagg>0.11.4... all hell is going to break loose for native addons
03:53:37  <rvagg>crazy crazy v8 api changes
03:54:22  <Raynos>rvagg: https://gist.github.com/Raynos/815cd4ff305f0253c678
03:54:40  <Raynos>rvagg: https://gist.github.com/Raynos/815cd4ff305f0253c678#file-gistfile1-txt-L63
03:54:45  <rvagg>Raynos: ugh, ok, yeah, I mustn't have released that
03:54:48  <rvagg>current repo version is ok
03:54:56  <Raynos>oh ok
03:54:57  <Raynos>sec
03:55:01  <rvagg>node_isolate was added in 0.11.1 and then removed in 0.11.3!
03:55:29  <rvagg>I might publish a new leveldown for current 0.11
03:55:30  <Raynos>xd
03:55:37  <Raynos>man
03:55:46  <Raynos>I was thinking of touching process.bindings directly
03:55:55  <Raynos>but that sounds like a breaking change disaster train
03:56:16  <rvagg>yea, but it's nothing compared to what 0.11.4 is going to bring
03:56:36  <rvagg>they've had to change pretty much everything that touches v8 in core because of v8 api changes
03:56:46  <Raynos>rvagg: https://gist.github.com/Raynos/2892919a823fb12ef194
03:56:48  <rvagg>it's going to be a nightmare to maintain 0.8/0.10 and 0.11 compat in the same thing
03:57:03  <Raynos>rvagg: https://gist.github.com/Raynos/2892919a823fb12ef194#file-gistfile1-txt-L61
03:58:18  <rvagg>right, that's the 0.11.3 Buffer changes! I fixed up most of the problems there
03:58:19  <rvagg>one mo
04:03:45  * timoxleyquit (Ping timeout: 264 seconds)
04:16:09  <rvagg>@0.6.2 being published
04:16:48  <rvagg>should be 0.11.3 compatible, will break compatibility with 0.11.2, unfortunately there's a node core argument about whether to increment NODE_MODULE_VERSION during the dev cycle, I can't target the changes in each 0.11 release unless they do
04:17:16  <rvagg>[email protected] in npm
04:17:19  * rvaggrevives levelbot
04:17:58  * levelbotjoined
04:17:59  <levelbot>[npm] [email protected] <http://npm.im/leveldown>: A Node.js LevelDB binding, primary backend for LevelUP (@rvagg)
04:26:06  <Raynos>rvagg: I think breaing v0.11.2 back compat is ok
04:26:17  <Raynos>I broke it in my gens module by bumping the patch version >_<
04:26:31  <Raynos>rvagg: nice leveldown installs cleanly on 0.11.3
04:37:35  * mikealjoined
04:38:29  <mikeal>would love to get some feedback from people on this
04:38:35  <mikeal>https://github.com/mikeal/SLEEP/blob/master/specs/wire.md
04:38:48  <mikeal>especially people who don't have experience with CouchDB
04:38:59  <mikeal>cause i'd like to get it flexible enough to handle anything
04:47:39  <Raynos>mikeal: you have a json document at the top
04:47:41  <Raynos>without any explanation
04:47:58  <Raynos>it would make more sense
04:48:04  <Raynos>to have it under the Response header
04:48:53  <mikeal>haha
04:49:10  <mikeal>yeah, i just broke this out of a larger spec that made even less sense
04:49:16  <mikeal>the issue is that, these "entries"
04:49:27  <mikeal>can be encoded in more than one way
04:49:29  <Raynos>mikeal: "An id MAY occure more than once during transmission. "
04:49:45  <mikeal>so, they could be returned in an array or in newline seperated JSON
04:49:46  <Raynos>it's not obvouis that id is the id of an entity and each seq is a version of that entity in time
04:49:52  <Raynos>that is only obvouis if your familiar with couch
04:50:15  <mikeal>it's not a version of the entity, it's a change to the "endpoint" (database or potentially an index)
04:50:45  <mikeal>it is a unique identifier for the underlying data
04:50:52  <mikeal>i should add that
04:52:07  <Raynos>mikeal: "An id MAY occure more than once during transmission. Clients MUST assume that the higher seq that is returned for an id replaces the previous entry. If the id occurs multiple times then the entries with lower seq numbers are effectively past representations of that data and should probably be considered out of date for a client"
04:52:11  <Raynos>something like that might help
04:52:52  <mikeal>ok, i just pushed an update to the definition of id
04:53:09  <rvagg>Raynos: I'm splitting up my leveljs stuff into a couple of different repos, will sync with you some time and you can have a hack if you like
04:53:12  <Raynos>mikeal: the _lat / _lng convention at the bottom feels out of place as its very specific where as the rest of the document is very generic
04:53:19  <Raynos>rvagg: cool :D
04:54:25  <mikeal>An **id** MAY occur more than once during transmission. Clients MUST assume that the higher **seq** that is returned for an **id** replaces the data for the previous *entry*. If the id occurs multiple times then the entries with lower **seq** integers are effectively past representations of that data and can be ignored or overwritten.
04:54:49  <Raynos>that sounds good
04:54:50  <mikeal>the _lat and _lng thing is a hold over from the previous spec, it'll go in to a better place eventually I just don't want to forget about it
04:55:09  <mikeal>rvagg: cool, what are you splitting up?
04:55:22  <rvagg>mikeal: leveljs-sst, leveljs-log, leveljs-coding
04:55:27  <rvagg>for now, while it's read-only
04:55:34  <rvagg>when it gets to writable then there'll be other bits
04:56:04  <rvagg>leveljs-log is pretty good at reading leveldb log files, leveljs-sst can do a partial job of reading sst files
04:56:51  <rvagg>i.e. goal is to have binary compatibility for leveldb in pure js; for a default implementation that doesn't require a compile, then you can compile if you need perf
04:57:11  <mikeal>very nice
04:57:33  <mikeal>btw, level-mutex is working quite nice
04:57:46  <mikeal>i'll have couchup-mapreduce working in the next week
04:57:59  <mikeal>and another database, level-sleep, done in about the same timeframe
04:58:11  <mikeal>also, couchup isn't a couchdb clone anymore
04:58:38  <mikeal>the more i got in to the rev tree stuff the more i realized how overly complicated CouchDB made it so that people can resolve their own conflicts, which they never do
04:58:55  <mikeal>so, i improved on the default resolution scheme
04:59:06  <rvagg>ahh, ok, but you'll still be able to sync with real couchdb tho?
04:59:07  <mikeal>and am writing couchup to use linear revision sequences
04:59:18  <rvagg>so we can replace npm's backend with it?
04:59:26  <mikeal>well, i'll be able to clone a CouchDB, and if you don't write to a couchup node you can continue to replicate
04:59:36  <mikeal>and you could push *new* documents to a CouchDB from couchup
04:59:43  <rvagg>ok
04:59:57  <mikeal>but if you try to three way sync, or write to a couchup node and then sync from CouchDB
05:00:01  <mikeal>you'll get unnecessary conflicts
05:00:25  <mikeal>when i do pull replication from CouchDB I basically convert their rev tree in a linear revision sequence
05:00:55  <mikeal>yeah, we'll be able to pull npm's backend in just fine
05:01:04  <mikeal>i'll still be able to replace npm at some point
05:01:17  <mikeal>there just won't be a point where some new npm and the old npm are master-to-master replicating with each other
05:01:40  <mikeal>i talked with isaacs a bit about what it would take to replace CouchDB
05:01:49  <mikeal>and full rev trees aren't exactly at the top of the list
05:02:00  <mikeal>modularized attachments are far more important
05:02:20  <mikeal>also, most of the npm API isn't raw CouchDB, it's list and show functions behind rewrites
05:02:33  <mikeal>so i can do those a lot simpler and faster as normal node.js code
05:02:47  <mikeal>but,
05:02:51  <levelbot>[npm] [email protected] <http://npm.im/leveljs>: LevelDB in pure JavaScript: coding and protobuf (@rvagg)
05:02:55  <mikeal>we will need to clone the current npm in order to migrate
05:02:59  <mikeal>which i'll be able to do
05:03:41  <rvagg>niice
05:04:01  <mikeal>you wouldn't believe how insane replication is for CouchDB
05:04:10  <mikeal>it's not just one GET of _changes
05:04:32  <mikeal>it then has to do a seperate GET *per document* *per branch of the rev tree*
05:04:47  <mikeal>if you delete a document and then recreate it, new rev branch
05:05:05  <mikeal>and that happens all the time in order to revert attachment failures
05:06:03  <mikeal>i'm just not going to re-write all of CouchDB's mistakes
05:06:20  <levelbot>[npm] [email protected] <http://npm.im/leveljs-coding>: LevelDB in pure JavaScript: coding and protobuf (@rvagg)
05:06:27  <mikeal>not when I don't know a single person that does a GET with _conflicts and actually uses this shit
05:07:43  <rvagg>aye, you have an opportunity to build on what they've learnt the hard way I guess
05:07:52  <rvagg>also a chance to make something more node-like
05:08:25  <mikeal>i just want the default conflict resolution to work as good if not better than CouchDB, being that it's how everyone uses CouchDB anyway
05:08:47  <mikeal>and it turns out
05:09:03  <mikeal>all those things people complain about in terms of performance have a lot to do with this one feature
05:09:51  <mikeal>so anyway
05:09:57  <mikeal>couchup readme is much differnet
05:10:18  <mikeal>and i'm trying to get SLEEP to a place where it's a generic replication scheme for any database or index
05:10:20  <levelbot>[npm] [email protected] <http://npm.im/leveljs-log>: LevelDB in pure JavaScript: log file reader / writer (@rvagg)
05:10:32  <mikeal>and then i'm going to write an extension for the linear revisioning couchup is doing
05:11:03  <mikeal>should all fit pretty nicely
05:12:20  <levelbot>[npm] [email protected] <http://npm.im/leveljs-sst>: LevelDB in pure JavaScript: sst file reader / writer (@rvagg)
05:13:20  <levelbot>[npm] [email protected] <http://npm.im/leveljs-log>: LevelDB in pure JavaScript: log file reader / writer (@rvagg)
05:14:42  * timoxleyjoined
05:16:54  * mikealquit (Quit: Leaving.)
05:17:26  <chapel>rvagg: isn't leveljs going to conflict with mbalho's leveljs?
05:18:21  * mikealjoined
05:20:24  <rvagg>chapel: no, he has level.js, I have leveljs, in npm his is level-js
05:20:36  <chapel>hmm
05:20:38  <rvagg>chapel: mine was in npm first, he asked if I didn't mind him using a similar name
05:20:40  * rvaggno care
05:20:42  <chapel>ah
05:20:44  <chapel>okay
05:21:02  <chapel>I think level.js and leveljs are the same thing to anyone that doesn't know
05:21:14  <rvagg>they'd find out they are different soon enough!
05:21:14  <chapel>just imo
05:21:17  <rvagg>take it up with max
05:23:08  <rvagg>I don't imagine leveljs will be as popular as level.js, if it does get used it might just be as a default dependency for levelup, giving you the option to install leveldown if you want the compile step
05:23:27  <rvagg>I don't believe it'd be something that many people would choose to install by itself
05:31:16  <mikeal>what i really want is a leveldown.js
05:31:36  <mikeal>that has indexedDB, localStorage and WebSQL
05:31:46  <mikeal>progressive enhancement :)
05:38:56  <rvagg>sounds like a job for Raynos or mbalho
05:39:06  <Raynos>:p
05:39:12  <Raynos>who needs progressive enhancement
05:39:18  <Raynos>just dont support non IDB
05:39:31  <mikeal>who writes websites! just write terminal clients in node.js for everything :)
05:52:14  * mikealquit (Quit: Leaving.)
05:52:21  * timoxleyquit (Ping timeout: 264 seconds)
06:12:48  * mikealjoined
06:23:01  * prettyrobotsjoined
06:33:37  * timoxleyjoined
06:38:14  * mikeal1joined
06:38:55  * gildean_joined
06:38:58  * chrisdicojoined
06:43:45  * mikealquit (*.net *.split)
06:43:46  * gildeanquit (*.net *.split)
06:43:49  * chrisdickinsonquit (*.net *.split)
06:52:08  <mbalho>the leveldown test suite runs in the browser now
06:52:28  <mbalho>the implementation is pretty easy
07:02:39  * chrisdicochanged nick to chrisdickinson
07:09:20  <levelbot>[npm] [email protected] <http://npm.im/leveljs-coding>: LevelDB in pure JavaScript: coding and protobuf (@rvagg)
07:09:50  <levelbot>[npm] [email protected] <http://npm.im/leveljs-log>: LevelDB in pure JavaScript: log file reader / writer (@rvagg)
07:10:34  <rvagg>fixed that baby, you can now `npm install leveljs-log -g` and your leveljs-log exe can be pointed at a *.log file in a leveldb store and it'll show you the contents, the export is just an EventEmitter that emits 'entry' events with key and value
07:44:50  <levelbot>[npm] [email protected] <http://npm.im/leveljs-sst>: LevelDB in pure JavaScript: sst file reader / writer (@rvagg)
07:45:07  <rvagg>and that one can read an sst, almost, it doesn't properly do shared prefixes but that's not hard to add, there's a few other things that need to be done
08:29:42  * timoxleyquit (Quit: Textual IRC Client: www.textualapp.com)
08:38:26  * timoxleyjoined
08:40:51  <levelbot>[npm] [email protected] <http://npm.im/level-store>: A streaming storage engine based on LevelDB. (@juliangruber)
08:42:51  <levelbot>[npm] [email protected] <http://npm.im/level-store>: A streaming storage engine based on LevelDB. (@juliangruber)
08:43:21  <levelbot>[npm] [email protected] <http://npm.im/leveljs-sst>: LevelDB in pure JavaScript: sst file reader / writer (@rvagg)
08:43:23  <rvagg>now it can do shared keys, w00t!
08:43:57  <rvagg>was actually pretty easy, I think my understanding of the leveldb internals has advanced quite a bit since I started leveljs
08:44:28  <rvagg>but alas, I should try and work on things that might pay the bills!
08:52:42  * dominictarrquit (Quit: dominictarr)
08:55:21  <levelbot>[npm] [email protected] <http://npm.im/level-store>: A streaming storage engine based on LevelDB. (@juliangruber)
08:57:51  <levelbot>[npm] [email protected] <http://npm.im/level-fs>: node's fs module with leveldb as backend (@juliangruber)
09:00:20  <rvagg>juliangruber: those *Sync methods might get a bit hairy
09:00:29  <juliangruber>rvagg: hell yeah
09:00:30  <rvagg>while (!callback) {};
09:01:10  <juliangruber>if (!sync) levelup(path) else leveled(path)
09:01:32  <rvagg>heh, ok
09:01:39  <juliangruber>or just add sync methods to levelup, #yolo
09:01:40  <juliangruber>:D
09:01:43  <rvagg>should get binary addons working properly so you could load in sync alternatives
09:02:05  <rvagg>need to sort out dependency compilation issues with npm first
09:02:26  <juliangruber>yeah, true, totally forgot about that possibility
09:03:52  <rvagg>it's possible now, just a bit messy with npm
09:20:59  * gildean_changed nick to gildean
09:47:12  * Acconutjoined
09:47:17  * Acconutquit (Client Quit)
11:32:25  * ralphtheninjajoined
11:36:33  * ralphtheninjaquit (Client Quit)
11:41:06  * ralphtheninjajoined
11:44:49  <juliangruber>rvagg: that should have been all no-bind pullrequests for now! level-fs's tests now run in phantomjs :)
11:45:35  <wolfeidau>juliangruber: +1 rvagg is a bind adict
11:45:43  <juliangruber>wolfeidau: :D
11:45:50  <levelbot>[npm] [email protected] <http://npm.im/level-fs>: node's fs module with leveldb as backend (@juliangruber)
11:47:20  <wolfeidau>I was messing with node-level-ttl today and didn't have much luck integrating it
11:48:32  <wolfeidau>Was it really neccessary to encode the TTL in the key?
12:23:04  * Acconutjoined
12:30:06  * Acconutquit (Quit: Acconut)
12:38:54  <rvagg>wolfeidau: the ttl isn't in the key, the expiry is but that's for a very good reason
13:45:36  * mcollinajoined
13:49:21  <levelbot>[npm] [email protected] <http://npm.im/level-fs>: node's fs module with leveldb as backend (@juliangruber)
13:59:50  <levelbot>[npm] [email protected] <http://npm.im/level-fs>: node's fs module with leveldb as backend (@juliangruber)
14:03:49  <levelbot>[npm] [email protected] <http://npm.im/locket>: A pure-JavaScript LevelDB implementation backed by a durable and persistent evented I/0 b-tree for use with LevelUP. (@bigeasy)
14:16:50  <levelbot>[npm] [email protected] <http://npm.im/level-store>: A streaming storage engine based on LevelDB. (@juliangruber)
14:32:20  <levelbot>[npm] [email protected] <http://npm.im/level-fs>: node's fs module with leveldb as backend (@juliangruber)
14:32:33  * thl0joined
15:22:50  <levelbot>[npm] [email protected] <http://npm.im/level-fs>: node's fs module with leveldb as backend (@juliangruber)
15:23:55  * mcollinaquit (Remote host closed the connection)
15:34:20  <levelbot>[npm] [email protected] <http://npm.im/level-fs>: node's fs module with leveldb as backend (@juliangruber)
15:57:44  * paulfryzeljoined
16:08:12  <thl0>juliangruber: is that level-fs module inspired by Plan 9?
16:08:25  <juliangruber>thl0: why would it?
16:08:30  <juliangruber>don't know too much about plan9
16:09:33  <thl0>juliangruber: http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
16:09:57  <thl0>juliangruber: concepts: all objects are either files or file systems
16:10:12  <juliangruber>thl0: aah, yeah that's nice
16:10:28  <juliangruber>the main motivation was fs in the browser
16:10:30  <thl0>i.e. same interface no matter what you are actually talking to -- everything is a file
16:10:32  <thl0>ah
16:10:34  <juliangruber>so i could use browserify in the browser
16:10:48  <thl0>that would be amazing
16:10:53  <thl0>good luck !
16:10:56  <juliangruber>and npmd in the browser :)
16:10:58  <juliangruber>thanks man
16:11:01  <thl0>:)
16:38:30  * st_lukejoined
16:39:10  * thl0quit (Remote host closed the connection)
16:39:51  * thl0joined
16:42:23  * thl0quit (Read error: Connection reset by peer)
16:42:55  * thl0joined
16:53:53  * thl0quit (Remote host closed the connection)
17:01:12  * dominictarrjoined
17:16:37  * mcollinajoined
17:23:56  * st_lukequit (Remote host closed the connection)
17:41:20  <levelbot>[npm] [email protected] <http://npm.im/level-store>: A streaming storage engine based on LevelDB. (@juliangruber)
17:45:51  <levelbot>[npm] [email protected] <http://npm.im/level-store>: A streaming storage engine based on LevelDB. (@juliangruber)
17:49:09  * no9joined
17:56:51  * mcollinaquit (Read error: Connection reset by peer)
17:57:38  * mikeal1quit (Quit: Leaving.)
17:58:16  * mikealjoined
18:02:18  * ramitosjoined
18:08:01  * thl0joined
18:13:16  <mikeal>dominictarr: responded to your SLEEP comments, updated the spec around seq, that's a good use case
18:13:35  <dominictarr>sweet
18:15:01  <mikeal>have some alternative ideas for node_id
18:15:23  <mikeal>also, should keep in mind that I intend to write *extensions* to this later on
18:15:50  <mikeal>like, for couchup, i want to write up my linear revisioning semantics, and add a .rev property
18:16:16  <mikeal>for multi-nodes we could add something that made that a bit nicer as well, but preserved the simpler base semantics
18:22:32  <no9>mbalho did you have any more thoughts about this > https://github.com/rvagg/node-abstract-leveldown/commit/402b51ad12d90d9d69e30448017db2e461d9530e
18:24:43  <no9>I think I mentioned it breaks alternative backends
18:27:46  * mcollinajoined
18:29:06  <dominictarr>no9: that should use bops!
18:32:18  <no9>dominictarr bops?
18:32:43  <dominictarr>https://npm.im/bops
18:33:13  <dominictarr>does binary ops on whatever is most appropiate
18:33:24  <dominictarr>Buffer in node, and typed array in the browser
18:33:48  <mcollina>dominictarr: thanks for merging in the level.js support in level-test! :)
18:34:10  <mcollina>dominictarr: have you published it on NPM? there is only 1.3.0 there.
18:35:24  <no9>Ah but the problem is I don't want the coarsion in the browser. bops or no bops :)
18:35:40  <dominictarr>mcollina: oops, is published now
18:35:49  <levelbot>[npm] [email protected] <http://npm.im/level-test>: get a clean levelup instance for testing. (@dominictarr)
18:36:16  <dominictarr>no9: oh, right - you don't need an encoding in indexdb
18:36:33  <mcollina>dominictarr: thanks!! :)
18:36:36  <dominictarr>hmm, maybe we can build that into the encoding
18:36:59  <dominictarr>https://github.com/rvagg/node-levelup/pull/149
18:37:08  <dominictarr>^ need to tidy that up
18:37:30  <dominictarr>and could then make the default encoding convert to string
18:37:55  <dominictarr>but would allow a noop encoding that returned objects.
18:39:20  <no9>Nice ask mbalho if it covers his use case when he turns up for the coffee :)
18:39:55  <no9>I was concerned it was going to get included in juliangrubers "NO BIND" commit
18:42:02  * mcollinaquit (Read error: Connection reset by peer)
18:47:18  * timoxleyquit (Quit: Computer has gone to sleep.)
18:49:57  <mikeal>every time i think something like those encoding options would be something i would use
18:50:06  <mikeal>i end up decided that i actually would not use them
18:50:17  <nathan7>How so?
18:50:29  <mikeal>only because there are cases where I end up getting something out of the database knowing that the purpose is to remove it
18:50:51  * st_lukejoined
18:50:54  <mikeal>or, i use peek or a range and the keys are used for additional puts and deletes
18:51:03  <mikeal>in which case, i don't want to decode and then re-encode them
18:51:19  <mikeal>it sucks because i do forget to properly encode keys sometimes
18:51:28  <nathan7>ah, keyEncoding
18:51:41  <mikeal>what i really wish is that there was a way for me to just have levelup throw if the key isn't a buffer
18:52:37  <mbalho>you want keys to always be buffers? that doesnt work in browser fwiw
18:53:04  <mikeal>TypedArray in browser
18:53:13  <mikeal>for my purposes they are actually compatible
18:53:29  <mbalho>idb only stroes string keys, same with localstorage
18:53:32  <mbalho>stores*
18:54:01  <mikeal>that is changing
18:54:07  <mikeal>idb spec has complex key storage
18:54:19  <mikeal>which is being prototyped using something like bytewise
18:54:23  <mbalho>well yea and the next version of javascript will have modules too :)
18:54:34  <mbalho>but we're all still here using npm
18:54:48  <mbalho>ok bad example
18:55:02  <mikeal>idb isn't available enough yet to be like "well it doesn't have it now so give up
18:55:15  <mikeal>it's only in newest browsers, where the update rate is actually rather high
18:55:39  <mbalho>all im saying is you cant use non string keys today in browsers
18:55:50  <mikeal>sure
18:56:53  <mbalho>mikeal: so why would you want levelup to throw if the key isnt a buffer?
18:57:25  <mikeal>right now i'm only using in node, and all my keys are buffers
18:57:35  <mikeal>but when i forget to encode them properly really bad bugs creep in
18:58:03  <mbalho>ah, got it
18:58:18  <mbalho>as long as its abstract like the encoding api that was discucsed in levelup/leveldown land recently
18:58:47  <mikeal>key/value validation at the levelup layer might be nice
19:00:26  <mikeal>none of my code will work without complex key storage, so it's not going to work in the browser for some time even if i wasn't using buffers to achieve complex keys
19:02:37  <dominictarr>mikeal: so, I have a PR for custom encodings
19:02:48  <dominictarr>: https://github.com/rvagg/node-levelup/pull/149
19:02:56  <mikeal>was looking at it
19:02:59  <dominictarr>where you pass in a encode and decode function
19:03:01  <mikeal>i don't think i'd use that
19:03:07  <dominictarr>you could just make that throw if it's not a buffer
19:03:18  <mikeal>ahhhh
19:03:20  <dominictarr>and have that callback an error
19:03:34  <mikeal>i'd want to throw actually
19:03:48  <mikeal>but it's nice to know i could use it for validation
19:04:36  <dominictarr>maybe it could emit a encoding_error event and you could throw in there?
19:05:01  <dominictarr>the idea of throwing here makes be feel uncomfortable...
19:07:08  <mikeal>it's a trap during development
19:07:20  <mikeal>every encoded write i have has a test
19:07:30  <mikeal>so it's not like i'd ship with this throw getting tripped up
19:07:54  <mikeal>it doesn't solve the problem of certain crazy bugs in my code where i try to bytewise encode NaN and it throws :)
19:07:57  <mikeal>but that already happens
19:09:00  <st_luke>ah I was just reading that issue
19:12:22  <dominictarr>mbalho: on my way now
19:12:23  * dominictarrquit (Quit: dominictarr)
19:12:30  <mbalho>sweet
19:29:42  * st_lukequit (Remote host closed the connection)
20:07:54  <levelbot>[npm] [email protected] <http://npm.im/level-object>: Store objects in leveldb. (@juliangruber)
20:09:41  * st_lukejoined
20:13:19  <juliangruber>writing level modules is so much fun :)
20:42:38  <st_luke>juliangruber: ++
20:43:43  <st_luke>mikeal: is couchup at a point where I can safely try it in production?
20:44:52  * levelbotquit (Remote host closed the connection)
20:51:20  * mreviljoined
21:07:37  * dominictarrjoined
21:08:18  * levelbotjoined
21:22:16  * thl0quit (Remote host closed the connection)
21:22:53  * thl0joined
21:27:23  * thl0quit (Ping timeout: 268 seconds)
21:41:03  * dominictarrquit (Ping timeout: 260 seconds)
21:56:36  * mrevilquit (Remote host closed the connection)
21:57:54  * jxsonjoined
22:00:42  <levelbot>[npm] [email protected] <http://npm.im/brash>: Browser-only terminal. (@juliangruber)
22:04:21  * jxsonquit (Remote host closed the connection)
22:07:22  <mikeal>st_luke: nope
22:07:39  <mikeal>you should play with it, but it's not ready for production by any means
22:07:46  <st_luke>mikeal: perfect
22:07:50  <st_luke>I'm gonna put it in production
22:08:01  <mikeal>right now i'm just trying to get feature complete while monitoring performance to make sure the way i implement things doesn't make it slow
22:08:07  <mikeal>hahah
22:08:21  <mikeal>luk is immune to warnings :)
22:08:42  <st_luke>mikeal: can you go to berlinjs to present it so the couchdb guys can realize that leveldb is not trolling anymore
22:09:15  <mikeal>i'll likely be in Berlin in September
22:19:53  <juliangruber>mikeal: sweet!
22:20:18  <juliangruber>st_luke: my live coding there was about leveldb and janl high fived me afterwards!
22:20:44  <mikeal>couchup has gone another direction anyway
22:20:54  <st_luke>juliangruber: leveldb can't do the kind of work that couch does, to say that it can is trolling
22:21:00  <mikeal>i couldn't live with myself just copying all of CouchDB's quirks
22:21:15  <juliangruber>+1
22:21:23  <mikeal>simplified the revision system and sacrificed custom conflict resolution for better automatic resolution
22:21:49  <juliangruber>mikeal: my spidey sense tells me that couch might have had more automatic resolution initially too
22:21:54  <mikeal>but it means that replicating back and forth between CouchDB and couchup will eventually cause conflicts on the CouchDB side
22:21:55  <st_luke>copying all of couch's quirks would be kind of boring anyway
22:22:40  <mikeal>juliangruber: nah, CouchDB has always used a full revision tree, and always had "most writes wins"
22:23:14  <mikeal>there is just some funky things that happen when documents are deleted and recreated that changes the semantics
22:23:15  <juliangruber>i see
23:07:12  <levelbot>[npm] [email protected] <http://npm.im/brash>: Browser-only terminal. (@juliangruber)
23:07:14  * mreviljoined
23:08:45  * mikealquit (Quit: Leaving.)
23:12:16  * mrevilquit (Ping timeout: 276 seconds)
23:12:25  * mikealjoined
23:14:47  * jxsonjoined
23:18:33  * paulfryzelquit (Remote host closed the connection)
23:19:11  * jxsonquit (Ping timeout: 240 seconds)
23:44:20  <no9>mbalho apologies completely misread the commit > https://github.com/rvagg/node-abstract-leveldown/commit/402b51ad12d90d9d69e30448017db2e461d9530e
23:45:59  <no9>It actually raised an issue in the level-gap stuff that I wasn't expecting because of the JSON type in the test
23:46:11  <mbalho>ahh oh yea
23:46:31  <mbalho>it would be nice if we landed dominics patch or whatever to allow leveldown implementers to plug in their own requirements
23:48:18  <no9>Yes I like where that lives in the stack alright but my issue was more of a constraint of using localstorage
23:49:26  <no9>What I mean is a still think I would have messed it up :)
23:49:46  <no9>But that patch would give a better solution than the one I have right now