not be extrapolated
easily to model more sophisticated ontologies. Tracker 0.6 metadata was
like apples and it proved insufficient for the needs of Nokia and
Nepomuk
jamie
On Thu, 2010-04-15 at 15:05 +0100, Bastien Nocera wrote:
On Thu, 2010-04-15 at 13:05 +0100, Martyn Russell wrote:
On 15/04/10 12:32
are
for shareable metadata only).
jamie
On Wed, 2010-04-14 at 18:04 +0100, Martyn Russell wrote:
On 14/04/10 16:10, Alexander Larsson wrote:
On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:
User defined tags
A completely flat view of all documents doesn't handle all users
or use cases
jamie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
of trackers storage abilities (something which they are
reluctant to do atm)
jamie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
none of the above are objections to inclusion of the shell,
just queries
jamie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
to fit gobject and our
platform perfectly with better Dbus integration
jamie
On Wed, 2009-11-04 at 13:04 -0500, Owen Taylor wrote:
On Wed, 2009-11-04 at 02:23 +0100, Christian Neumair wrote:
2009/11/2 Owen Taylor otay...@redhat.com:
GJS and SpiderMonkey: Currently gnome-shell is build using
important stuff like file, application and web
histories.
I personally would like to merge zeitgeist functionality into tracker
but really its up to the zeitgeist team on whether they are willing to
do this (it would mean converting the python code to Vala/Genie or C as
well)
jamie
On Fri, 2009-10-30 at 11:18 +0100, Murray Cumming wrote:
On Fri, 2009-10-30 at 00:08 -0400, Jamie McCracken wrote:
The problem is that to leverage the full power of
tracker, you need much deeper integration and its not practical to
make
it optional in those cases
bold decisions. Playing it safe
means it will stagnate and Gnome will miss out on all the cool
technology.
jamie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Thu, 2009-10-29 at 23:13 -0400, David Zeuthen wrote:
On Thu, 2009-10-29 at 19:38 -0400, Jamie McCracken wrote:
this is all hypothetical. What matters is that people actually try it
out then make judgements based on whether the current tracker gives a
good experience. If people dont do
, too.
Therefore, your solution isn't future-prove, either.
Whatever shell is used in Gnome 3 will at some point likely provide an
out of process applet system (especially if enough people scream!)
jamie
___
desktop-devel-list mailing list
desktop
There has to be migration - i can never remember all my evo account
settings and im sure in corporate environments it would be a major
source of technical call outs
If it were for only Gnome 3 then maybe an exception can be made but for
gnome 2.x, migration is critical IMO
jamie
On Fri, 2009
then its a non-issue and a migration script can easily be written
using gconftool and dconftool
if not I would suggest supporting that
jamie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop
of an admin to easily copy a branch
of config settings. Thats trivial in gconf and I use it for copying
settings between machines (cp ~/.gconf/blah)
So whats needed is perhaps some import/export branches of settings to
xml that would enable something similar
jamie
I would rephrase this as valac as a build dependency for gnome
as valac is like yacc/bison/flex in that there is no runtime dependency
and only people developing or compiling from git will need it (tarballs
and distributed source will contain the generated c files so wont be
needed there)
jamie
it an excellent storage medium and
with all querying left to tracker and sqlite you can get the best of
both
jamie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
indexing or file monitoring nor does it cosume
significant resources
jamie
On Tue, 2009-08-18 at 17:07 +0200, Lennart Poettering wrote:
On Tue, 18.08.09 13:05, Martyn Russell (mar...@lanedo.com) wrote:
Hi all,
So we recently polled the tracker mailing list to make sure the core
developers
On Tue, 2009-08-18 at 16:18 +0100, Martyn Russell wrote:
On 18/08/09 16:18, Jamie McCracken wrote:
The indexer part is optional
Well, right now it isn't but it will be at some point sure.
The main part tracker-store is just a database with querying and is to
be used by zeitgeist
On Tue, 2009-08-18 at 17:20 +0200, Patryk Zawadzki wrote:
On Tue, Aug 18, 2009 at 5:18 PM, Jamie
McCrackenjamie.mccr...@googlemail.com wrote:
The indexer part is optional
The main part tracker-store is just a database with querying and is to
be used by zeitgeist
If the consensus
or .git folder that houses a repository
and automatically skip that folder sub tree
Most devs will use grep rather than tracker for searching source files
anyhow and I have never come across a situation where indexing soure
repositories is useful (there may be corner cases of course)
jamie
On Tue, 2009-08-18 at 17:50 +0200, Steve Frécinaux wrote:
Xan Lopez wrote:
It can be used directly by applications that feed it data through an
API. Zeitgeist is an example, another could be bookmarks/history
storage in Epiphany.
Do you mean storing actual bookmarks into the database ?
On Tue, 2009-08-18 at 16:57 +0100, Martyn Russell wrote:
On 18/08/09 16:57, Jamie McCracken wrote:
On Tue, 2009-08-18 at 16:44 +0100, Martyn Russell wrote:
On 18/08/09 16:07, Lennart Poettering wrote:
On Tue, 18.08.09 13:05, Martyn Russell (mar...@lanedo.com) wrote:
Hmm. The beef I have
On Tue, 2009-08-18 at 17:02 +0100, Martyn Russell wrote:
On 18/08/09 17:03, Jamie McCracken wrote:
On Tue, 2009-08-18 at 16:57 +0100, Martyn Russell wrote:
We already do that. But some projects have a LOT of directories ;)
do we? It still indexes all source files for me. Just to be clear
On Tue, 2009-08-18 at 16:11 +, Colin Walters wrote:
On Tue, Aug 18, 2009 at 3:32 PM, Jamie
McCrackenjamie.mccr...@googlemail.com wrote:
we could use the Gtk Recent files stuff for this and that would work for
ordinary users but not devs fetching source code or other command line
On Tue, 2009-08-18 at 19:40 +0200, Philip Van Hoof wrote:
On Tue, 2009-08-18 at 17:14 +0100, Martyn Russell wrote:
On 18/08/09 17:11, Colin Walters wrote:
On Tue, Aug 18, 2009 at 3:32 PM, Jamie
McCrackenjamie.mccr...@googlemail.com wrote:
we could use the Gtk Recent files stuff
On Tue, 2009-08-18 at 19:21 +0100, Michael Meeks wrote:
Hi Jamie,
On Tue, 2009-08-18 at 11:32 -0400, Jamie McCracken wrote:
Couldn't you just make gio (or gedit or OpenOffice) notify you every
time it closes a file instead of monitoring bazillions of files? I'm
not very likely
sure there are many more...
jamie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Tue, 2009-08-18 at 20:57 +0200, Lennart Poettering wrote:
On Tue, 18.08.09 14:48, Jamie McCracken (jamie.mccr...@googlemail.com) wrote:
On Tue, 2009-08-18 at 20:26 +0200, Vincent Untz wrote:
Le mardi 18 août 2009, à 20:19 +0200, Philip Van Hoof a écrit :
We'll do our best
and inotify anyway (it will
never work on NFS in any event). We certainly dont want trackers
progress held up by kernel slackage
I believe getting GVFS to emit a ring buffer log file of timestamped
changes would be suffice for tracker to get into gnome and avoid
extensive crawling and monitoring.
jamie
and even the new trendy gnome-shell
obsolete.
Of course docks have their weak points too but atm they are the best and
least complex UI for a desktop and a more natural evolution from our
existing gnome-panel than anything else I have seen.
jamie
to simple text files if neither dbus nor dconf were present
we badly need a configuration facility in glib so all glib apps can use
it much like gio does to gnome-vfs. That in itself is a good enough
reason for the change
jamie
___
desktop-devel-list
Also I would imagine a dconf-editor app would not be practical without
schemas especially for settings of type bool/enum where you want a
checkbox/dropdown
jamie
On Fri, 2009-04-03 at 09:20 -0400, Havoc Pennington wrote:
Hi,
On Fri, Apr 3, 2009 at 8:27 AM, Vincent Untz vu...@gnome.org wrote
but want c speed and efficiency then there is no
better language
jamie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
executable code directly. It has a lot of the
features of c# and java and can also be debugged via gdb
for now it cross compiles into c but its a mistake to assume its just
syntactic sugar!
jamie
___
desktop-devel-list mailing list
desktop-devel-list
On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
On Sun, 2007-12-02 at 15:36 +, jamie wrote:
Vala of course - http://live.gnome.org/Vala
Rewriting every application in another language isn't the answer for
resource usage. Not that Vala is bad, on the contrary it seems nice
already knowing Ant to adopt
its a nice idea
I guess whats needed is some kind of converter to convert to and from
xml and autofoo with appropriate macros and/or xslt
I guess the only snag is finding a volunteer to do it - which most
likely means you!!! :)
jamie
for it but not sure how much it
covers
the gtk/nautilus code should be deprecated in favour of xesam in the
coming months
jamie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
coming from the
online desktop.
(the UI frontend or applet can remain in python of course but the
interface to the online world should be C if possible)
jamie
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org
will
require IPC anyhow and we definitely want this stuff in our core
platform libs if we want them to become ubiquitous
And as other have pointed out, Dbus is widely used on embedded systems
so I cant see any reason to hold back on this.
Just my thoughts
jamie
simpler implementation of this but without
all the complexity and steep learning curve of an rdf based sematinc web
store.
We can pretty much do anything nepomuk does but without requiring or
exposing rdf semantics.
jamie
___
desktop-devel-list mailing
of semantic based metadata as you
describe above.
My talk on having a central metadata db like tracker/nepomouk at Guadec will
offer solutions to these cases
jamie.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org
don't offer those here?
NP - I will make slides available after my talk
Its probably a bit premature to have a long thread on ddl discussing
this at this point (at least until more apps are using tracker's
database - via XESAM hopefully)
jamie
will be as fast as holding it in memory but without the
need to waste any (thats why using a db like sqlite is so much smarter -
sql is massively more productive to work with and performs tons faster
than parsing text files)
jamie.
___
desktop-devel
On Tue, 2007-02-06 at 08:29 -0500, JP Rosevear wrote:
On Tue, 2007-02-06 at 10:14 +, jamie wrote:
On Mon, 2007-02-05 at 21:19 -0600, Federico Mena Quintero wrote:
El mar, 06-02-2007 a las 12:52 +1100, Russell Shaw escribió:
If profiling has to be done to make a menu faster
On Tue, 2007-02-06 at 11:26 -0300, Claudio Saavedra wrote:
Quoting jamie [EMAIL PROTECTED]:
Yes and its fairly easily fixed with tracker once I add .desktop file
indexing to it
They are already indexed in beagle, so it would be fairly easy to do
this with libbeagle right
On Tue, 2007-02-06 at 11:07 -0500, JP Rosevear wrote:
On Tue, 2007-02-06 at 13:43 +, jamie wrote:
On Tue, 2007-02-06 at 08:29 -0500, JP Rosevear wrote:
On Tue, 2007-02-06 at 10:14 +, jamie wrote:
On Mon, 2007-02-05 at 21:19 -0600, Federico Mena Quintero wrote:
El mar, 06-02
On Tue, 2007-02-06 at 11:49 -0500, Joe Shaw wrote:
Hi,
On Tue, 2007-02-06 at 08:29 -0500, JP Rosevear wrote:
On Tue, 2007-02-06 at 10:14 +, jamie wrote:
On Mon, 2007-02-05 at 21:19 -0600, Federico Mena Quintero wrote:
El mar, 06-02-2007 a las 12:52 +1100, Russell Shaw escribió
the sqlite index would also interest deskbar as it needs fast
access to desktop files)
jamie.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Tue, 2007-02-06 at 20:24 +0100, BJörn Lindqvist wrote:
On 2/6/07, jamie [EMAIL PROTECTED] wrote:
On Mon, 2007-02-05 at 21:19 -0600, Federico Mena Quintero wrote:
El mar, 06-02-2007 a las 12:52 +1100, Russell Shaw escribió:
If profiling has to be done to make a menu faster
process
file change notifications while running on battery power.
thanks thats a good idea (I assume I can use dbus to get the info so
dont have to depend on any gnome stuff)
please consider adding enhancement requests to:
http://bugzilla.gnome.org/browse.cgi?product=tracker
--
Mr Jamie
Joe Shaw wrote:
Hi,
Jamie McCracken wrote:
point 2 is scheduled at nice +19 (same with Ionice +7) so it only uses
more cpu if its idle.
That's not quite how the nice level works, at least in Linux. Higher
nice values get a shorter timeslice, so they merely have less time to
get
needs.
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Joe Shaw wrote:
Hi,
On Mon, 2007-01-08 at 20:47 +0100, Steve Frécinaux wrote:
Jamie McCracken wrote:
in any event tracker can be configured to not index at all or only index
metadata and/or contents. It can also be used a stand alone metadata DB
so I think tracker should be flexible
Joe Shaw wrote:
Hi,
On Wed, 2007-01-10 at 16:26 +, Jamie McCracken wrote:
Joe Shaw wrote:
[snipped my concerns about Tracker]
all these also apply to EDS too yet no one complains?
Some of them apply. EDS isn't a general data store; it has APIs and
backends that are very specific
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
player, find video
for in your video player, find contacts, email and everything in less than a
split second!
yes that is a good approach
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list
with some
tweaking as others have suggested - especially places menu)
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
to search apps.
Its much better to have the general search/deskbar applet as it is (an
applet in the panel)
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org
also add that nautilus search without beagle or tracker is
barely usable and appallingly slow so its not only the new menu thats
suffering here.
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel
tracker should be flexible enough for most cases where you
only want a subset of its features.
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo
criticisms should have been
met.
API churn is not relevant to desktop modules AFAIK although I am
expecting only minor adjustments there.
* (http://www.grillbar.org/wordpress/?p=173)
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop
Steve Frécinaux wrote:
Jamie McCracken wrote:
in any event tracker can be configured to not index at all or only
index metadata and/or contents. It can also be used a stand alone
metadata DB so I think tracker should be flexible enough for most
cases where you only want a subset of its
ended but I
expect the default should be no search until at least tracker gets
into GNOME :)
(Tracker is still under proposal for Gnome 2.18)
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel
Ross Burton wrote:
On Wed, 2006-10-25 at 23:10 +0100, Jamie McCracken wrote:
The RDF way would be (triples):
hasPersonalEmail --- rdfs:subPropertyOf --- hasEmail
hasWorkEmail --- rdfs:subPropertyOf --- hasEmail
RossBurton --- hasWorkEmail --- [EMAIL PROTECTED
Shaun McCance wrote:
On Wed, 2006-10-25 at 11:20 +0100, Jamie McCracken wrote:
James Doc Livingston wrote:
What would be really cool is support for field groups, but that would
probably require a fairly large change. So you could do things like
correctly storing the release dates when a track
types,
but that is necessary for the metadata to stay useful when doing
generic queries.
yeah thanks that makes sense
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http
Vincent Untz wrote:
Le mardi 24 octobre 2006, à 21:33, Jamie McCracken a écrit :
It would be nice as tracker is a freedesktop thingie to avoid evolution
I've read several times that tracker is a freedesktop
thingie/project/insert another word here. Do you mean it's desktop
agnostic or do
James Henstridge wrote:
On 25/10/06, Jamie McCracken [EMAIL PROTECTED] wrote:
You would need to completely flatten the metadata as
Contact.HomeJabberID, Contact.WorkJabberID etc so that all metadata is
mapped 1:1
If you do flatten things like this, I would hope you'd still be able
to query
James Doc Livingston wrote:
On Tue, 2006-10-24 at 21:33 +0100, Jamie McCracken wrote:
A contact can only have one metadata value per type (this is a primary
key constraint)
With everything mapped 1:1 you can then use RDF query to search them
On Tue, 2006-10-24 at 23:39 +0100, Jamie
Ross Burton wrote:
On Wed, 2006-10-25 at 11:12 +0100, Jamie McCracken wrote:
With everything mapped 1:1 you can then use RDF query to search them
Why would you need a 1:1 mapping to do a query? A query for contacts
with an email of [EMAIL PROTECTED] should be possible
independent
Ross Burton wrote:
On Wed, 2006-10-25 at 11:20 +0100, Jamie McCracken wrote:
looking at evolution's contacts screen it does not look like its support
more than one work email (it has home, work and other)
Incorrect, the type is a combo. If you want to add four work email
addresses
Ross Burton wrote:
On Wed, 2006-10-25 at 11:20 +0100, Jamie McCracken wrote:
Not being able to handle multiplicative metadata would make some things
very awkward. For example what should happen with music that has
multiple artists? I think that supporting multiple values for a piece
Jamie McCracken wrote:
I'm thinking of decent genre support, so multiple genre tags per song
(as supported in Ogg). If a song has Song.Genre=Post Rock,Ambient and
I search for rock, will the substring search incorrectly match the
song?
Yes it will unfortunately - hopefully these corner
Nick Murtagh wrote:
Jamie McCracken wrote:
Contact.HomeEmailAddress : [EMAIL PROTECTED];[EMAIL PROTECTED]
Contact.WorkEmailAddress : [EMAIL PROTECTED]
note using semicolon as delimiter so contents would need to be escaped
for the semicolon. I guess standardising on semicolon delimiters
James Henstridge wrote:
On 25/10/06, Jamie McCracken [EMAIL PROTECTED] wrote:
James Henstridge wrote:
While having standard names for metadata relationship types that
everyone can use is great, there are going to be cases where apps want
to experiment with relationships that haven't yet
Ross Burton wrote:
On Wed, 2006-10-25 at 11:41 +0100, Jamie McCracken wrote:
I'm thinking of decent genre support, so multiple genre tags per song
(as supported in Ogg). If a song has Song.Genre=Post Rock,Ambient and
I search for rock, will the substring search incorrectly match the
song
Ross Burton wrote:
On Wed, 2006-10-25 at 14:06 +0100, Jamie McCracken wrote:
I do wonder why nobody has taken a fast database-backed RDF triple store
(from librdf), put a sparql-based frontend on it for queries (again from
librdf) and used re-used a lot of code from both Beagle and Tracker
to answer them on this list but that should
not have any bearing on whether tracker is adopted or not.
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org
Wouter Bolsterlee wrote:
2006-10-25 klockan 12:27 skrev Jamie McCracken:
Ross Burton wrote:
On Wed, 2006-10-25 at 11:12 +0100, Jamie McCracken wrote:
With everything mapped 1:1 you can then use RDF query to search them
Why would you need a 1:1 mapping to do a query? A query for contacts
for love
in all the wrong places. They fight crime!
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
or not it
wont make a difference to the functionality tracker offers.
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Don Scorgie wrote:
Hi,
On Tue, 2006-10-24 at 00:07 +0100, Jamie McCracken wrote:
Jeff Waugh wrote:
quote who=Jamie McCracken
t-s-t uses the same code as g-s-t so it inherits the working code. Its a
better search tool because it can show search snippets like google as well
as providing
Sanford Armstrong wrote:
On 10/24/06, Don Scorgie [EMAIL PROTECTED] wrote:
Hi,
On Tue, 2006-10-24 at 00:07 +0100, Jamie McCracken wrote:
Jeff Waugh wrote:
quote who=Jamie McCracken
t-s-t uses the same code as g-s-t so it inherits the working code. Its a
better search tool because it can
Dan Winship wrote:
On Mon, 2006-10-23 at 21:26 +0100, Jamie McCracken wrote:
First to clarify, tracker is not a dedicated indexer (like Beagle and
Strigi) but is first and foremost a database which has indexing as a
side feature.
Are there any *currently existing* GNOME applications
then I will
reconsider (If any experts in that area wish to supply me with the
equivalent metadata in the spec I will seriously consider it)
(probably best to do so on tracker mailing list to avoid more noise on
d-d-l before we get complaints)
--
Mr Jamie McCracken
http
Luca Ferretti wrote:
Il giorno gio, 19/10/2006 alle 03.10 +0100, Jamie McCracken ha scritto:
Hi,
We have just released a new stable version of tracker (0.5.0) which can
be found here:
http://www.gnome.org/~jamiemcc/tracker/tracker-0.5.0.tar.bz2
I would like to propose this for inclusion
James Henstridge wrote:
On 24/10/06, Jamie McCracken [EMAIL PROTECTED] wrote:
Ross Burton wrote:
On Tue, 2006-10-24 at 23:26 +0800, James Henstridge wrote:
I think that the idea Ross is trying to get across here is that rather
than having a flat namespace of metadata types, you want
Luca Ferretti wrote:
PPS what about a bugzilla entry?
I asked for one about 6 months ago (I emailed the bugzilla team but got
no reply)
If anyone could help set up a bugzilla entry that would be great (or
point me to the appropriate procedure)
--
Mr Jamie McCracken
http
Evandro Fernandes Giovanini wrote:
Em Ter, 2006-10-24 às 17:09 +0100, Jamie McCracken escreveu:
The only thing slowing down further integration is getting into gnome or
being an accepeted dependency - hopefully a chicken and egg situation
can be avoided here
Why don't you create
Ross Burton wrote:
On Mon, 2006-10-23 at 23:21 +0100, Jamie McCracken wrote:
The main reason was I didn't like the way GNOME uses loads of different,
inefficient and incompatible means of storing information (think
Berkeley DB for EDS, MBox for emails, the zillions of small performance
Ross Burton wrote:
On Tue, 2006-10-24 at 20:04 +0100, Jamie McCracken wrote:
Only Files at the moment. We have preliminary Email support but its not
complete yet. The Api would be specific to each object and would be
analogous to the methods on a class.
Can you point to the API
Ross Burton wrote:
On Tue, 2006-10-24 at 21:33 +0100, Jamie McCracken wrote:
Next up we would define the basic metadata or properties of the object
(EG Contact.FirstName, Contact.Surname, Contact.EmailAddress etc along
with their types) and add these to the metadata types table
$ grep EVC_
is rather hard.
Dublin Core is part of it. It names some types of metadata. I've
already mailed about this with Jamie in the past . In my opionion, the
issue should be separated into smaller definitions that say, what
metadata fields can be extracted from certain filetypes. Indexer
plugins could
so
that it can be imported by all three.
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Mariano Suárez-Alvarez wrote:
On Mon, 2006-10-23 at 21:26 +0100, Jamie McCracken wrote:
First to clarify, tracker is not a dedicated indexer (like Beagle and
Strigi) but is first and foremost a database which has indexing as a
side feature.
Jamie, can you please explain what exactly
Hubert Figuiere wrote:
[ cross-post reduced d-d-l ]
Jamie McCracken wrote:
Some people might not like that but I think its a practical compromise.
With tracker being the only one written in pure C it is therefore the
only one that can *ultimately* get into the Gnome platform and be fully
Jeff Waugh wrote:
quote who=Jamie McCracken
As this stage I am simply proposing tracker-search-tool as a replacement
for the gnome-search-tool as I believe it does a better job with faster
instant search and search snippets.
That was not entirely clear from previous emails in this thread
Jeff Waugh wrote:
quote who=Jamie McCracken
t-s-t uses the same code as g-s-t so it inherits the working code. Its a
better search tool because it can show search snippets like google as well
as providing high speed search.
And it does so by using... Tracker? Which means you're not just
Jeff Waugh wrote:
quote who=Jamie McCracken
sorry, is anything else still unclear?
Go back to my mail, read it again, and start from the beginning. What is it,
what does it do, why is it important? Tell us a story with an elevator pitch
and use cases, not an essay with hypotheticals
Jeff Waugh wrote:
quote who=Jamie McCracken
(okay here goes - now that I have looked up what an elevator pitch is!
I will try to be brief...)
This is a pretty airy-fairy description for a developer mailing list. Your
audience is not my Mum, it's the group of people architecting GNOME
1 - 100 of 154 matches
Mail list logo
