On 06/12/2014 03:56 PM, Mariusz Wojcik wrote: > > Back to the topic Basket rewrite, my initial plan was to use Qt 4, but > now I think I will use for the rewrite Qt 5/QtQuick. The Basket rewrite > would solve the windows port issue and it would clean up the current > code base. Maybe introducing a new version of the .baskets file format. > My idea is to replace xml with json and gzip with lzma.
I wondered if Windows was your reasoning. Another good reason to do so would be to remove the KDE libs. I have no idea what they give us, so maybe they're very useful and we shouldn't get rid of them, but they do add another barrier to porting. It's fairly obvious what QT gives us. As for XML versus JSON, you're trading 1 gnarly format for another gnarly format, IMO. ;) As for compression, why? I have a lot of data in OneNote (150M), but that's no big deal. Even if OneNote compresses (which I don't know), I suspect I wouldn't have more than 500M if that were expanded, which still isn't an issue that I can see. One good thing about not having the data compressed, it's a whole lot easier to look at it with other tools if you need to. :) In the FWIW department, I just saw a benchmark between gzip and lzma. While lzma might compress a little better (like 10%), it's was 3x slower than gzip. Something to keep in mind. Of course, it's also possible that baskets are small enough it won't matter (the benchmark was on a 203M file). If you decide to compress, it would be good to have that be an option, so the user can decide which they want to do. > > Regarding Onenote, Kevin have you read the .one [file format > specification](http://bit.ly/1lkFiGO) from Microsoft? No I haven't, so thanks for the link. It's interesting that they documented it so thoroughly. I believe there is also a .NET lib (or VB or something) that they make freely available to help out too; it's the way you're supposed to write "OneNote Toys" (which I've never done). However, I'm presently investigating the idea of having the user dump the Notebook to HTML, then parsing that to create the baskets & notes. The reason to go that route is that the baskets are HTML, so that would mean I don't have to worry about that bit of conversion, and parsing HTML is reasonably easy (most of the time). At this point in time, I think I'm going to prototype that in Perl since it's so good at string handling, and once I get the basics working, then I'll do the equivalent in C++. Or maybe I'll just say that converting is a 1-time thing and is really a utility, so it stays in Perl. ;) Obviously, my mind's not made up and I'll probably change it a few times before the end. There may also be technical reasons to do one over the other that I've yet to discover. I haven't made it very far, but I do have a new conversion option in the UI working with a stub for the actual code ... that was a lot harder than I thought it would be, :( which probably shows my inexperience with QT. Kevin ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Basket-devel mailing list Basket-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basket-devel
