Fix building with aeson >= 0.6.2.0 and hashable >= 1.2

[DanielG]

aeson

deriveJSON now takes an Option record instead of a single function. It might be nicer to define a function that takes the fieldLabelModifier function rather than doing it inline everywhere but I didn't know where a good place to put that would be.

hashable

hashWithSalt is now the minimal implementation

[pxqr]

That's a good idea.

It might be better to make a new exposed module, say Data.Torrent.JSON, which:

• export a couple of Options datatypes so it's possible to make more uniform APIs;
• describe conventions so it's clear (from documentation) how exactly objects mapped to JSON values.

[DanielG]

Sounds good.

I would've done it nicely but I only just started looking at the source and don't know my way around yet ;) Just submitted the pull request to let you know there are some issues with newer library versions.

btw. is it just me or is src/Network/BitTorrent/Exchange/Assembler.hs completely broken atm.? I had to comment out the whole file to get the library to build at all.

[pxqr]

There are a lot of (commented in cabal) broken modules, most of them are just outdated. Some dependencies are outdated too, for example I should replace IntervalMap in storage to plain old Vector and binary search since storage don't need insert/delete operations. Currently the package make migration from dirty'n'prototypish version to something more consistent. Things like Assembler are just "ah, now I know how to make this right and want just to dump it until I forgot". (ok, I admit, I need to use branches more often) (btw assembler is used to get rid of any notion of blocks/transfer/exchange from the Storage.hs)

So, most stable part is Data.Torrent.* modules and they are slowly released at hackage. System.* modules will be rewritten as well as Exchange.* modules. DHT is not even tested before.

Now I concentraited on Tracker subsystem, in particular I want to hide HTTP/UDP tracker protocols under single interface so it's possible to make session-level layer protocol independent. A good place to start to hack is somewhere around Tracker.RPC.Message, at least it should compile! ;)

[DanielG]

I see, that's too bad. I was looking for a bittorrent protocol implementation I could use for some experimenting (that doesn't involve having to deal with f*ing c++ ;). What's the state of the actual inter peer protocol handling? My use case depends on a working DHT and p2p metadata exchange so I could test/add that code.

[pxqr]

Yes, currently these parts are completely unusable. So you want to perform lookup :: InfoHash -> Torrent, am I right?

[DanielG]

Pretty much yeah :)

I couldn't find a single bittorrent client that just lets me do that.

[pxqr]

That shouldn't be too hard to implement, at least core protocol is much more complex to implement right. But I don't know how long time it might take. At this point it's easier to just use libtorrent I guess.

[DanielG]

I would rather not touch C++ ;) I'll try to evaluate how hard it would be to get those bits of the library working so expect me to keep bothering you ^_^

[pxqr]

Ok. :)

Then I'll start to work on P2P messaging.

[DanielG]

Are you planing to rewrite much of Network.BitTorrent.Exchange.Message? I need somewhere to start hacking. Also, are you around on IRC somewhere (preferably freenode ;) so we can coordinate somehow?

[pxqr]

Well, seems like #haskell-bittorrent is free.