In practice, I believe that has worked rather well. While I have received emails from folks who try to store 10,000 books in their database and find the performance lacking, by and large, I've seen many reviews note favorably that Tellico is simple and flexible to use and can be useful for the majority of people.
I do want to expand Tellico's capabilities, however. One large goal is to get away from treating each collection as a flat list of entries. I want to be able to have books and movies in the same database, for example, and I want to be able to track TV episodes and seasons equally well. I want to be able to add information about authors and actors.
To that end, I need to rewrite Tellico's backend. And in considering how I want to do that, I've come to a decision point about SQL vs. RDF.
Many highly-visible KDE applications use SQL, such as Amarok, Digikam, and Akonadi. I just read a blog post about using the same MySQL instance for all three of those applications.
On the other hand, the Nepomuk framework in KDE provides an interface to an RDF database. Bangarang and KMail 2 are both heavily using Nepomuk.
So I'm trying to work up a pro/con list.
I want to say that SQL wins. Embedding or linking against SQLite means a typical user would never need to worry about database permissions, daemon persistence, or username and port settings. At the same time, for power users, the added work to make MySql or PostgreSQL an option, would be reasonable. Akonadi and Digikam have taken this approach, and up until recent versions, so had Amarok.
Using Nepomuk, on the other hand, requires the full Soprano and Virtuoso tool chain. Most KDE desktops are running Virtusoso at this point, I guess, but I don't want to shut out the GNOME users out there. And on my underpowered development box with 1 GB of RAM, I can't even use Strigi and Nepomuk.
Here again, I think SQL wins. SQL (and to some extent, SQLite) is used in so many places, I know a significant amount of work has gone into optimizing and improving its efficiency. In other words, if the database access is slow, it's very likely that the problem is due to my poor programming knowledge rather than a fundamental flaw. I don't have that reassurance with RDF/SPARQL and Nepomuk. i know Nepomuk is improving, but looking at the bug reports and development fits and starts in the KDE code, it still seems a bit rocky.
SPARQL also has some weird semantics, such as blank nodes, a need for custom Insert/Replace behavior, and a lack of aggregate functions. SPARQL is still rather immature, in that sense.
I feel like I should include this factor. RDF seems to be a bit of a buzzword with the semantic database push lately.A SQL schema would largely be opaque, while the RDF store, assuming the use of common ontologies, would allow for future interoperability with other databases. This is all rather fuzzy, though, and there's nothing that says I can't have some sort of RDF export or translation from the SQL.
If I did use Nepomuk and RDF, I might even have to try to write some sort of abstraction layer to use Tracker on GNOME.
I'd call this a tie! I've messed around with some limited SQL and RDF/SPARQL both, and I'm interested in learning more about both.
It's always interesting to me to read what specific features or workflows each review mentions. This particular review gave step by step instructions for installing and running Tellico on Kubuntu, and then basic steps for adding information about a book to Tellico. It also included information for creating a custom collection (which I don't usually think about most users doing) and using a filter for finding items in a collection.
It didn't appear to have any comments about drawbacks or bugs (other than a quick aside about needing to register for an Amazon API key). The article includes a nearly identical review of GCstar, basically walking through installation, running, and adding a book.
One note of interest to me, as well, was in comparing the screenshots between Tellico and GCstar and looking at the translations of the user interface in French. I guess it doesn't always register to me that there are so many ways of saying the same thing, especially in English and no different in French. Slightly different verb tenses or phrasing...
]]>The previous release was back in February, so this one has quite a few bug fixes and some new features. Freebase was added as a data source, which is rather useful. Freebase has tons of info available, and is constantly being updated. It even has some limited comic book information, too.
I messed up some of the links on the download page, so embarrassingly enough, for a few days after the release, the links were broken. Those should all be fixed now!
I also jumped off the deep end and downloaded Choqok and registered on identi.ca which is something like the open source version of Twitter. Much less popular, so by definition, much cooler! Software nerds use it a good bit, I've heard. Anyways, I took the handle stephero. (Strike that, since changed to AstroRobby for uniformity with Twitter.)
One of the primary features I'd like to work on for the next version of Tellico is better statistics. I'm looking forward to working with the KDE plot widgets.
]]>Other collection management software allows management of these items but GCStar has jumped out ahead of competitors because the software allows you to catalog your favorite television shows directly from TVBD channels and allows you to catalog mini vehicles. Cataloging mini vehicles will require some manual efforts but the detailing offered is priceless.
GCstar is a fantastic bit of software. In my opinion, one of its biggest strengths is the sheer number of websites that it can scrape for info. Tian, the primary GCstar author, even added a feature for using GCstar as a standalone data fetcher. As a result. Tellico can use any of the GCstar data sources directly. The interface is a bit slower, but it works pretty well. I'd like to make Tellico as modular and useful in return, but haven't been able to yet.
Congratulations to GCstar!
]]>I'm happy to report that no source code changes are necessary for Tellico. While the bump in the Yaz version means a library ABI compatibility, it's still source-compatible.
]]>At first glance, Tellico seemed like the obvious winner of the bunch. It's got built-in templates, it's configurable and provides good documentation. The design is elegant, if not pretty, but it's been superseded by a superior program, one that's pushed the heights of what a collection manager can be.
Near as I can tell, Tellico loses out to GCstar's shiny templates! Well, I can take that. It's a pretty good article, though with not much in the way of substantial critiquing.
Even though you don't have to fill in all, or even most, of the fields, the result is unappealing. The dialog boxes you use to fill in the information for an item are crowded, but there are also all the ugly empty spaces from fields you didn't fill in.
I think the author is hitting two points there. I understand the crowded dialog complaint, though aside from doing in-place editing in the view, I can't think of any other way to edit the data. The second point, about showing empty fields in the view, is easily fixed with some tweaks to the default. Maybe I should add a template for that as an option.
Tellico's website provides a detailed illustrated guide in addition to the extensive documentation, but the drawback to having extensive built-in support is the in-your-face interface that comes with it, although this is more than offset by the program's features. When filing our comic book collections, we honestly don't want to enter the date we purchased the book, so we find it irritating that Tellico expects us to.
Definitely a valid point there at the end of that paragraph. That's why Tellico 2.0 added a field for automatically storing the date that the comic book was first added to the collection as well as the date of the last modification of the comic book data. I decided not to remove the default field for year of purchase, though maybe I should have.
Feel free to edit or comment.
http://techbase.kde.org/Projects/Tellico/Compiling
http://userbase.kde.org/Tellico
Update: Compilation instructions are properly on KDE TechBase instead of UserBase so I moved them.
]]>]]>On December 18, 2009 Novell Forge will be decommissioned. No further access will be available to project contents.
Everyone at LibraryThing disagrees with this decision. LibraryThing is not a social cataloging and social networking site for Amazon customers but for book lovers. Most of us are Amazon customers on Tuesday, and buy from a local bookstore or get from a library on Wednesday and Thursday! We recognize Amazon's value, but we certainly value options.
Importanly, the decision is probably not even good for Amazon. Together with a new request-monitoring system, banning iPhone applications that use Amazon data, and much of their work on the Kindle, Amazon is retreating from its historic commitment to simplicity, flexibility and openness. They won through openness. Their data is all over the web, and with it millions of links to Amazon. They won't benefit from a retreat here.
Tim Spalding and the gang at LibraryThing have always struck me as being very clear-minded in their goals and the best way to help their users. I agree with their assessment.
]]>The ironic thing is that I appeared to have created the problem when I updated the export code to allow me to write unit tests for it. HTML export works fine in the test, but Tellico, the app, was setting the configuration wrong. All the articles I've read about there being no such thing as a harmless code change are true!
So, my apologies if you download Tellico, created a collection, tried to export your HTML page and promptly get a crash. We'll hire new Quality Assurance people immediately.
]]>As always, I get rather nervous when I finally get up my courage to make a release. Five times out of 10, I do something stupid and mess up some portion of it. Maybe the i18n configuration, or forgetting some debug code, or adding in a fix that doesn't work. And then I'll get one or two angry emails about it.
But on the whole, this is a rather rewarding exercise. Number one, my wonderful wife is downstairs making brownies for us to celebrate. Number two, the number of positive, complimentary emails that I receive far outweigh the negative ones. Number three, I love scratching that itch of programming something that helps me!
This is a .0 release, ported to a new platform. So I expect there to be some whopper bugs in there. I've started adding more unit tests, particularly for the data sources and the translators, and those have certainly caught more than a few mistakes on my part. But there are bound to be bugs, so backup your data file if you care about your data!
Moving the Tellico website, source code repository, mailing list, and bug database was no small task either. I have received a lot of help and support from folks on the extragear mailing list, the KDE sysadmins, and many others who take the time to send me suggestions, feedback, and bug reports. Thank you very much!
I don't have a grand plan for further feature development, at the moment. My thoughts of migrating to a full SQL backend have been shelved. I'm toying with the idea of adding some sort of RDF integration, maybe using the Nepomuk framework. There are also a few additional formats and sources that I would like to add to Tellico. The sky's the limit!
]]>I think he wrote a fairly straight-forward piece, though my wife thinks his quote of my blog post made me sound a bit cold-hearted. Sorry, folks. You’ll just have to use a different search source. Yeah, maybe I could have phrased that better. And I actually think I can backport the implementation fairly quickly to the KDE3 version of Tellico. Just as soon as I get Tellico 2.0 out...
Like any internet article, some of the comments are insightful and some are confused. One accuses me of being a freetard/leech, one confuses application keys with Amazon Associates IDs, and then one guy says:
"Tellico had the same key. It was hard-coded in the source."
Rather shoddy coding practices on display there, me old mucker.
"Some other application could have used the same key, since it was pretty much public, though"
If you're an administrator, then you'll be wanting to keep close tabs the server load which you're shouldering out of sheer generosity, so it’s of no surprise that they’ve clamped down on security if these open source idiots have been handing out their security keys willy-nilly.
I think this guy forgets what open-source means. Here's a hint, it means the source is open. Before the authentication requirement, Tellico used an Access Key, purely for identifying the request as coming from Tellico. It wasn't for security. Sure, you could argue that Tellico should have been requiring users to register for and obtain those keys on their own, from Day 1. In fact, I'll tentatively agree with you. But by far, the number of desktop applications that utilized the Amazon API, used the Access Key as a way of identifying the generator (application) of the request rather than the source (user) of the request.
I can see this being the driving motive for private keys. Amazon are allowing these (non-profit generating) database queries out of good will, despite these apps clearly being in violation of the T&C (you're not going to purchase a book or album from Amazon, which you're software has just catalogued you as clearly already owning.)
I've been criticized at least once for including Tellico's Amazon Associate's ID as the default setting for HTML export and linking. And true, out of the box, all the Amazon links in Tellico use that ID as essentially, the referrer. But it's also one of the easiest settings to change, and was included as a config option for the Amazon data source from the beginning. In fact, you could have multiple Amazon sources, each with a different Associates' ID affiliated with it.
While the affiliate ID has not generated that much in referral fees, it shows that a significant number of people are browsing Amazon products that are linked from Tellico's HTML export. But maybe the comment writer does have a point. Now, with the requirement that each user provide a secret key, the onus for ensuring that Amazon's Terms & Conditions are met falls on the user rather than the developer.
If you're a Mac user, check out Delicious Library. Also notice that it doesn't give you the option of changing the exported affiliate code. And at first glance, their update to Delicious Library for Amazon's API switch doesn't appear to require a user-obtained key as Tellico does. Anyone want to argue that DL has, as its primary purpose, advertising and marketing the Amazon Site? I think that serves as pretty good corroborating evidence of the practices followed by Tellico...
But I do resent being called an open-source idiot! Just for the record...
]]>As a result, the Amazon searching no longer works for any version of Tellico released for KDE3. I don't plan to try to backport that support, either.
Sorry, folks. You'll just have to use a different search source.
By the way, Alexandria has hit the same issue. Books for Macos X hit it, too.
]]>This release has not been tested by many people yet. If you are not comfortable trying pre-release software, don't. It may trash your home directory, kill all the whales, and take your dog hostage.
If you'd like to test it, please backup your data first!. The image handling and document loading were both significantly modified, and since they are the crucial components, you should have data backups.
I posted a longer list of new features and notes over on the project website.
Incidentally, I think I'll start posting news bits over on tellico-project.org and keep blogging about Tellico here at periapsis.org. The news posts there will have comments enabled, too.
]]>I took a leap and decided to use Drupal as the CMS. I thought about Wordpress, too, but I wanted to learn something new. I think I figured most of it out, but there are still a few tweaks to be made. I'm about 90% happy with the layout and design.
Most of the links from the periapsis.org domain have redirects setup for them and will continue to work.
Also, the mailing list has moved to the kde.org domain. At the moment, Gmane has updated its information. Nabble has not.
]]>