liten project goals for 0.2 version

1 view

Skip to first unread message

Noah Gift

unread,

Mar 23, 2010, 1:31:47 AM3/23/10

to li...@googlegroups.com, Rob Orsini, Kennedy Behrman, jya...@comcast.net, rjo...@imagemoversdigital.com

Hi,

The liten project has largely remained dormant, except for the brave work of techtonik. Alfredo Deza also worked out another alternate approach using sqlite and SQL which is fairly interesting as well. A few people I know recently where interested in helping on this project, and they are now interested in becoming more actively involved. I happen to work professionally with Rob, Kennedy, and Jeremy, and we practice 100% code coverage, branching to work on tickets, and code review of anything that goes into the trunk. How does everyone feel about using that same approach to come up with a new version of liten?

Because we are using mercurial it would be nice to figure out in the next week, a strategy that works well for everyone. I personally like the decentralized approach that allows eventually goes into a central repository.

Here are some ideas, feel free to jump in anyone, for items we might want to look at for 0.2: http://code.google.com/p/liten/wiki/RoadMap Some of these things might be a bit old though. One idea would be to do a general clean up and merge what we can from Alfredo's liten2 project into our project and get to 100% code coverage.

Alternately, I know a few guys are interested in jumping right into a multi-threaded PyQT GUI that would sit on top of liten. We could technically split up into two groups of people. One group could work on making the disk walking and de-duplication algorithm really, really fast, 100% testable, and easily extended into an API, and the other group could work on the GUI? We could start by making tickets for each of these sub projects, and going from there. The other thing to mention is that we need some sane filtering algorithms, because it is quite useful to only deduplicate or merge *.mp3, in /music....

Also, we should think about scalability from the start. If someone wants to run our software on 10TB's of storage, is it an automatic fail? Can we make it horizontally scalable, with process pools, for example? I don't know, but this is fun stuff!!!

This isn't a rush for anyone of course, but it is fun stuff. What could the end result look like? Well, if we created a cross platform GUI that not only did de-duplication, but did left and right merge, that would be pretty killer. The use case I am thinking of is merging a friends "music player" device onto your machine, in a sane way.