Il giorno ven, 09/04/2010 alle 18.09 -0400, Owen Taylor ha scritto:
I've attempted below to extract out some of the technical bits from
http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding
and see how they line up with our current technology. This is just
notes, not yet a
On 04/15/2010 02:05 PM, Martyn Russell wrote:
If you had a real database,
Are you suggesting SQLite is not a real database or that an application
would use a real database to continue your point?
I think what Bastien meant is if tracker exposed itself as a real
database, i.e. exposing a SQL
On 19/04/10 10:53, Steve Frécinaux wrote:
On 04/15/2010 02:05 PM, Martyn Russell wrote:
If you had a real database,
Are you suggesting SQLite is not a real database or that an application
would use a real database to continue your point?
I think what Bastien meant is if tracker exposed
On 15/04/10 15:05, Bastien Nocera wrote:
On Thu, 2010-04-15 at 13:05 +0100, Martyn Russell wrote:
It's neither, and that means that you need to learn a new query
language.
snip
I couldn't this time last year either (and that's not a benchmark for
how long it takes to learn either).
I don't
On 15/04/10 15:25, Emmanuel Pacaud wrote:
There is also the actual standard we try to follow:
http://www.semanticdesktop.org/ontologies/
NIE, NCO, NMO, SCAL, NAO, MTO, NMM, XSD: WTF ? :)
I agree, they need some love. But if you know SPARQL already, it isn't
so cryptic. That doesn't
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. Frequent filers will want
On Mon, 2010-04-12 at 11:31 +0100, Martyn Russell wrote:
On 10/04/10 22:10, Owen Taylor wrote:
On Sat, 2010-04-10 at 11:43 -0400, Jamie McCracken wrote:
On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:
Well, certainly tracking and indexing file metadata doesn't *require*
anything as
On 15/04/10 12:32, Bastien Nocera wrote:
On Mon, 2010-04-12 at 11:31 +0100, Martyn Russell wrote:
On 10/04/10 22:10, Owen Taylor wrote:
On Sat, 2010-04-10 at 11:43 -0400, Jamie McCracken wrote:
On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:
Well, certainly tracking and indexing file
On Thu, 2010-04-15 at 13:05 +0100, Martyn Russell wrote:
On 15/04/10 12:32, Bastien Nocera wrote:
On Mon, 2010-04-12 at 11:31 +0100, Martyn Russell wrote:
On 10/04/10 22:10, Owen Taylor wrote:
On Sat, 2010-04-10 at 11:43 -0400, Jamie McCracken wrote:
On Fri, 2010-04-09 at 18:09 -0400,
Is it entirely true that RDF/Sparql, whilst giving us the power to model
stuff better, is harder to use and makes things more difficult to devs
who dont know it
I had always imagined there would be a client library that did not
expose RDF/SParql which would allow for more simple use and queries
On Thu, 2010-04-15 at 10:34 -0400, Jamie McCracken wrote:
Is it entirely true that RDF/Sparql, whilst giving us the power to model
stuff better, is harder to use and makes things more difficult to devs
who dont know it
I had always imagined there would be a client library that did not
On Thu, 2010-04-15 at 15:05 +0100, Bastien Nocera wrote:
snip
I couldn't this time last year either (and that's not a benchmark for
how long it takes to learn either).
I don't think your case is a good one, given that you worked on Tracker
almost exclusively during that time.
Well, to
(Replying selectively - lots of stuff snipped that I agree with)
On Tue, 2010-04-13 at 21:18 -0500, Federico Mena Quintero wrote:
On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:
I've attempted below to extract out some of the technical bits from
On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:
I've attempted below to extract out some of the technical bits from
http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding
and see how they line up with our current technology. This is just
notes, not yet a concrete plan.
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. Frequent filers will want to be able to identify
projects and other subsets of files.
One way around all this is to provide interfaces which could use tracker
or something else for base storage and notification of changes.
In the future tracker may use CouchDb for storage of tags/notes and
other user input metadata as being able to import/export to/from the
cloud and across
On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:
I've attempted below to extract out some of the technical bits from
http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding
This is great stuff. I feel kind of bad commenting from the sidelines,
given that I have done
On 10/04/10 22:10, Owen Taylor wrote:
On Sat, 2010-04-10 at 11:43 -0400, Jamie McCracken wrote:
On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:
Well, certainly tracking and indexing file metadata doesn't *require*
anything as complex, or general purpose as RDF. I have some concerns
about
On 12/04/10 12:03, Martyn Russell wrote:
On 09/04/10 23:09, Owen Taylor wrote:
I should just add, we are not starting the performance optimisations. Up
Sorry, that's ...we are *now* starting...,
--
Regards,
Martyn
___
desktop-devel-list mailing
Hey,
I'd like to provide some information in relation to the concerns
raised about information being stored separately in Zeitgeist and
Tracker. The example case of asking for all music files played within
the last week can be solved using only a single Zeitgeist query;
however, you are right
Hi,
On Sun, Apr 11, 2010 at 12:10 AM, Owen Taylor otay...@redhat.com wrote:
Well, certainly tracking and indexing file metadata doesn't *require*
anything as complex, or general purpose as RDF. I have some concerns
about the complexity, but as long as we don't get to the point where
Hi!
There are two basic approaches here - one is to avoid storing
things on the Desktop. Instead of seeing the Desktop as a separate
location in the file selector, you'd have a checkbox:
[ ] Pin to Desktop
(or whatever the designers come up with), and that would create
Le samedi 10 avril 2010 à 09:10 +0200, Johannes Schmid a écrit :
Hi!
There are two basic approaches here - one is to avoid storing
things on the Desktop. Instead of seeing the Desktop as a separate
location in the file selector, you'd have a checkbox:
[ ] Pin to Desktop
On Sat, 2010-04-10 at 09:10 +0200, Johannes Schmid wrote:
Hi!
There are two basic approaches here - one is to avoid storing
things on the Desktop. Instead of seeing the Desktop as a separate
location in the file selector, you'd have a checkbox:
[ ] Pin to Desktop
On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:
Tracker
===
In some testing, Tracker 0.8 seems enormously better behaved
than Tracker 0.6. It has very significant optimizations in how
it stores the tracker database on disk, and also, by default,
only indexes defined subdirs of
On Sat, 2010-04-10 at 11:43 -0400, Jamie McCracken wrote:
On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:
Tracker
===
In some testing, Tracker 0.8 seems enormously better behaved
than Tracker 0.6. It has very significant optimizations in how
it stores the tracker database
On Sat, 2010-04-10 at 00:25 +0100, Alan Cox wrote:
The other approach is when expiring or archiving to move files
from ~/Desktop to an archival location like ~/Documents.
How does moving it work with non aware applications or a shared file
space ? You risk opening a file having it
On Sat, 2010-04-10 at 17:10 -0400, Owen Taylor wrote:
The reason I consider storage relevant is that throwing data into an
optimized SQL database where you don't have any ability to control what
is indexed or understanding how query plans are executed is usually a
recipe for application
I've attempted below to extract out some of the technical bits from
http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding
and see how they line up with our current technology. This is just
notes, not yet a concrete plan.
- Owen
File management ideas and technology
The other approach is when expiring or archiving to move files
from ~/Desktop to an archival location like ~/Documents.
How does moving it work with non aware applications or a shared file
space ? You risk opening a file having it moved, saving it and ending up
with a copy in documents and
30 matches
Mail list logo
