Re: bumping telepathy-glib's external dependencies for 2.32

2010-04-11 Thread Andre Klapper
Am Donnerstag, den 01.04.2010, 11:01 +0200 schrieb Guillaume Desmottes:
 I plan to use in Empathy new API from telepathy-glib so will have to
 dump the external dependency to 0.11.
 This will be needed for new features and factor out code from Empathy to
 tp-glib.
 
 Hope that's fine.

No feedback for a week, hence go ahead.
Please update the corresponding 3.0 moduleset in jhbuild and
http://live.gnome.org/TwoPointThirtyone/ExternalDependencies .

andre
-- 
 mailto:ak...@gmx.net | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: External dependency bump on libgdata for 2.31

2010-04-11 Thread Andre Klapper
Am Dienstag, den 30.03.2010, 08:53 +0100 schrieb Philip Withnall:
 Hi,
 
 Would it be possible to bump the external dependency on libgdata up to
 version 0.6.4 for the 2.31 release cycle? The work on adding libgdata
 support to Tracker[1] has come up against a nasty bug[2] which is only
 fixed in libgdata 0.6.4
 
 Besides that, there are many other improvements in libgdata 0.6.4 over
 version 0.3 which are worth having, such as much better support for the
 features of many Google services.

No feedback for a week, hence go ahead.
Please also update the corresponding 3.0 moduleset in jhbuild and
http://live.gnome.org/TwoPointThirtyone/ExternalDependencies .

andre

-- 
 mailto:ak...@gmx.net | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: Finding and Reminding, tech issues, 3.0 and beyond

2010-04-11 Thread Zeeshan Ali (Khattak)
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
 understanding RDF and ontologies is a prerequisite for developing a
 GNOME app, we're probably fine.

  In order to achieve this goal, Tracker will have to provide APIs
specifcally tailored for specific purposes. The only hurdle there is
that Tracker developers seem to be very insistent on Sparql to be
*the* API every application should be using to communicate with
Tracker. I would really love to be wrong about that but thats the
impression I got when trying to convince Tracker guys to implement the
MediaServer[1] API.

 But if we go beyond that and start encouraging people to start putting
 all sorts of application data into Tracker and relying on Tracker to do
 efficient queries on it, then it definitely is a concern. Based on how
 Tracker is mapping RDF into SQL tables, some SPARQL queries are going to
 be fast, some are going to be dead slow and people need to be able to
 come to an understanding of which are which.

  I think the 'custom APIs for specific purposes' approach will
minimize such performance issues since in that case both
application(s) and Tracker will know exactly what is expected from the
very start. For example, I am using optionals in my queries in Rygel
and I observed that they make the queries very slow. I was told (by
Tracker developers) that the solution is to use property functions
instead. I haven't gotten around to change this but I am affraid it'll
require not only miner changes but some redesign of the code.

  Now if Tracker implemented the MediaServer spec I mentioned, I would
have just informed Tracker guys which API is slow and it would have
been upto them to optimize it. i-e I wouldn't have needed to even know
about optionals and property functions, let alone to change/redesign
my code to make the queries faster.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] http://live.gnome.org/Rygel/MediaServer2Spec
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list