Re: [Tracker] Roadmap to 0.7

On 12/07/09 13:11, Ivan Frade wrote:


  Thinking about the future of tracker-search-tool (understand t-s-t as
a end-user program), i see only 4 options:

a) Kill tracker-search-tool. Focus on the daemon, and let external apps
be our UI.

This is not a good idea. People expect some sort of UI to show off what you can do with Tracker. Without this people quickly loose interest when trying the project out. Not to mention, if we have a UI, we have a tool to test our engine with.

The importance of this should not be underestimated at all :)

b) Quick fix the current t-s-t (modify the code to use sparql and some
dirty hacks to keep everything similar).

Well, I would remove the directory and create something new with a new name too.

Jamie I would also do this in another branch so we can review it before merging to master.

c) Rewrite t-s-t (probably in a different language) with the same UI.

I personally would elect for Vala since we already use that. I haven't seen what Genie is like though so...

I definitely wouldn't do it in C though - might even make sense to use Pygtk because it will be fast and demonstrate language compatibility.

d) Write a brand new t-s-t with a brand new UI that shows how powerful
is the daemon.

Well, as I put on the current roadmap, there is currently NO way to control Tracker in 0.7 from the UI. The DBus API we have right now has no control at all. Carlos and I want to work on a base class for each miner so we can list them all in an applet or UI and be able to control them and see the progress of each of them. This would also allow the user to pause all or specific miners.

  We have also three "milestones" in tracker in the near future:

1) 0.7.0 release

Right. I want to get this done in the next month or so. I am not sure exactly how quickly Jamie can do the UI, but it all hinges on him I think. We should have the other parts done by the time the UI is ready.

I would also like to update the website for the release so we have a new look there too! People didn't know there was one from my impression at the summit.

2) 0.7.x cycle

Once a month is my suggestion - as a minimum too.

3) for the stable 0.8 release

As an additional note here, speaking to Bastien at the summit, he recommended we get Tracker into GNOME and release with those schedules so we align ourselves with other distros (Ubuntu/Fedora/etc). I think this makes sense.

Any views on that?

  So, we can combine different decisions and moments (E.g. quick hack
for 0.7.0 and new UI for 0.8) (or in chess notation: b1, d3).

Yea, I don't think that will work. As stated above, as soon as you announce something, if the user has nothing to try other than a bunch of command line utils, they won't be impressed. It is better to have something (even if it is simple and fast) than nothing visually.

  My opinion: At some point we should get rid of t-s-t (or revamp it
into a developer tool). With the new architecture, tracker is not a user
program anymore, but an efficient backend for applications.

Well, that sounds pretty much like what tracker-explorer is. We already have that in the tree so we should just build on that IMO.

  0.7.x are development releases, not intended for distribution (i.e.
end-users), and we want a release ASAP because some applications are
interested in testing it. So i prefer to focus in _documentation_ and
stability than waste time on the UI. To remove t-s-t in 0.7.0 or to fix
it quickly to release soon is fine with me. We can add it again later if

Well, applications can still checkout unreleased master if they want to get a feel for Tracker. Releasing is about us saying we are ready not about doing it for applications.

The UI won't take long and it will be a tool to test the engine anyway just like your GLib unit tests are.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]