Re: New module proposal: tracker
On Tue, Nov 10, 2009 at 10:28 AM, Rob Taylor rob.tay...@codethink.co.uk wrote: Iain wrote: On Mon, Nov 9, 2009 at 12:01 AM, Philip Van Hoof s...@pvanhoof.be wrote: Sorry but, with DBusGProxy you already have a GObject that you can immediately connect a signal to and get informed when something gets added, removed and changed. http://live.gnome.org/Tracker/Documentation/SignalsOnChanges With DBusGProxy you also already have a GObject to make a SPARQL query. You just have one method called SparqlQuery that takes a string, and that returns an array of an array of strings. It can't get much more simple than that. Except that with libtracker-client you don't even have to think DBus anymore. I saw the DBus API, I just didn't seriously think you were proposing it as application facing API. Porting the QTtracker library (or writing a high-level GObject equivalent) should be a priority if you want to get Tracker accepted by GNOME. As John mentioned earlier, see: https://labs.codethink.co.uk/index.php/p/sparql-glib/ I'd be quite happy to propose this as a GNOME module. It probably needs some cleaning and tidying but is completely usable at this point. Thanks, Rob One option is that some of this code could be merged into tracker itself, if it is deemed useful, along with exposing TrackerSparqlBuilder (which might be internal atm? can't remember). Just an option, but i'm not strictly in favor of that as i had hoped to see it able to access other SPARQL endpoints like dbpedia.org. That said, theres no reason it couldnt support multiple endpoint types, as im sure the miners would love to query such repositories online. The main problem with sparql-glib as it stands is that it stands is that its still quite low level. You are essentially building an AST by hand and then sparql-glib flattens that into sparql. For the common case we need to come up with something a little higher level i think. Like gobject property getters (pass in multiple properties to fetch, it builds and uses the AST to get sparql). However for complicated queries with lots of relations to other resources this approach won't be as useful, i think. I'd like to see jalchemy merged in to sparql-glib too, as that is really just a wrapper to make using sparql-glib less verbose from js land. John iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Rob Taylor, Codethink Ltd. - http://codethink.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Sun, Nov 8, 2009 at 8:43 PM, Iain i...@gnome.org wrote: Tracker 0.7 ships with a DBus API, Nepomuk as ontology, SPARQL as query language, SPARQL UPDATE for inserting and updating data and finally signals-per-classes as life search capability. The DBus APIs are simple but very powerful thanks to SPARQL. From looking at tracker again this weekend, and indeed it does work better than the last time I checked in June (modulo some apparent big bugs and some issues with the concept that I couldn't test due to the bugs) but from a application developer point of view, I'm still disappointed. Essentially, I feel the APIs are far too low level and the documentation is very very incomplete, which ended up leaving me wandering around in dark as to what I was meant to do. The Application Development Manual is useless (I know its not finished, but its no help at all). I know you guys love love love ontolgoies and SPARQL and predicates and all that, but honestly, as an application developer I couldn't care less. All I want is to get at the data I want in the easiest possible way, and looking at tracker and discovering that I need to learn yet another language and a whole new load of boring concepts to do that is very offputting. SPARQL, tuples, ontologies should be internal details that you shouldn't need to know about. While I agree that the terminology is a little buzzwordy and perhaps even scary to newcomers, i want to start with a rather defensive point: sqlite (or any database) isnt any better out of the box. I think all C apps using sqlite are quite low level and SQL has to be manually written? Things are better in python where we have ORM but people often go low level anyway beecause they want to be fst. But I agree. We can do better here. In addition to the things Philip has mentioned you might want to look at tralchemy, a python helper for working with tracker. Right now this is an experimentation area for what we can build on top of the tracker store. A couple of things it does: * It dynamically binds all the ontologies (schemas) tracker knows to python objects similar to traditional python ORM tools. The bindings don't needed to be updated for new ontologies, it just works. * This means simple queries can be as easy as Contact.get(firstName=John) * To add a new records is c = Contact.create(); c.firstName = John; c.commit() * Help works on classes: from tralchemy.ns import nco; help(nco.Contact) * Event propagation - Contact.connect(added, callback). Though this might be disabled in HEAD pending some refactoring. * For more complicated queries, there is an experimental JSON representation of SPARQL. tralchemy has 2 cousins - jalchemy (JavaScript) and sparql-glib (vala). They were developed to the point where they were useful for an application but currently tralchemy is more actively developed (read: experimented on). All of them can be found on labs.codethink.co.uk. Looking at tracker/src I see 7 things begining with libtracker- and none of them look overly helpful. The most useful looks like libtracker-client, but again its too low level. What I would really like to see is some simpler high level calls that enable me to get all data of (for example) Music, allow me to specify what fields I want, and it should be a GObject that I can connect to signals on to find out when a result has been added/removed/changed. AFAIK, most of the libtracker- things are internal. I believe there has been some discussion about how a dynamic gobject binding might look, but no volunteers to write it yet. I would love to see some proposals for what the API might look like, everything i can think of severely limits the queries that are possible or is excessively verbose. I wrote an example of the excessively verbose kind, sparql-glib.. We should be looking to make our APIs as simple and easy to use as possible to enable developers to make the applications without distracting them with irrelevant implementation details. If this already exists, I apologise and blame the lack of documentation. iain John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
Hi, On Tue, Oct 27, 2009 at 8:58 AM, Martyn Russell mar...@lanedo.com wrote: On 27/10/09 03:34, Sriram Ramkrishna wrote: On Mon, Oct 26, 2009 at 4:08 PM, Andre Klapper ak...@gmx.net mailto:ak...@gmx.net wrote: Am Dienstag, den 18.08.2009, 13:05 +0100 schrieb Martyn Russell: I would like to propose Tracker as a new GNOME module. The GNOME release-team will soon decide about module inclusions for GNOME 2.30. To the GNOME developers: If you have not commented yet, if there is anything to add, if you have questions to the maintainer: Please comment now. I have one comment and I think from a marketing perspective, I would like to see that we are on par with the other desktops. OSX has spotlight, and I believe windows has winfs or at least it has something built in. We are doing ourselves no favors when we are not feature complete against other desktops. Carlos Garnacho and I did spend 2 or 3 days writing an application similar to spotlight - although it is just a quick mock up to demonstrate the speed and ability of Tracker and could do with some more love. The blog/video about it is here: http://blogs.gnome.org/mr/2009/09/30/tracker-0-7-released/ I am though a little disheartened that they had such a hard time coming up with use cases. :/ Hi all, Since posting the initial request a lot has changed. 0.7.0 up to 0.7.4 versions have been released, we are doing weekly releases now too. After some brief talk on IRC, we are considering making stable releases from the end of the year or so. Regarding use cases, this is how it is being used now (0.7.x that is) Maemo platform (I may have missed some cases): * Calendar * Bookmarks * Image Viewer * Media Player * Instant Messaging (I think) Could you expand on what this means? Is tracker being used as the primary store for calendar in Maemo now? Or is it just indexing the calendar. Etc. For the desktop: * Totem - http://blogs.gnome.org/mr/2009/10/07/tracker-totem/ * Evolution * File system (of course) * Applications (desktop files) Here its just acting as an indexer and putting stuff in the RDF store, right? And consuming data in totems case? In the works: * Zeitgeist * Photo management application - work done by Debarshi Ray * Epiphany developers were looking into using it - progress unknown. * We have a branch we are currently looking into merging with web application support (facebook, flickr, twitter, etc) - work done by Adrien Bustany (GSoC student). The web miners are awesome. Perhaps Bastien will change his opinion now I fixed up his app :P -- Regards, Martyn John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30
Hi, On Thu, Oct 1, 2009 at 12:42 PM, Rodrigo Moya rodr...@gnome-db.org wrote: Hi Purpose === couchdb-glib is a library to implement the protocol to talk to CouchDB servers (http://couchdb.apache.org), a schema-free, json-based, database of documents, which offers synchronization and replication between several machines. evolution-couchdb is the 1st module to make use of couchdb-glib, to allow contacts from Evolution to be stored in CouchDB databases and replicated/synchronized for free to other CouchDB servers. Target == couchdb-glib for the developer platform evolution-couchdb for the desktop Dependencies couchdb-glib depends on json-glib, libsoup, libuuid and (optionally) libssl (for OAuth authentication) evolution-couchdb depends on couchdb-glib, evolution-data-server and evolution I've not looked at evo-couchdb, is the intention that there would be a local couchdb instance or that it would connect directly to a remote couchdb? If there is a local couchdb exepected for the common case then maybe the mozilla js dependency needs a mention. Resource usage == Source code is already in GNOME's git (couchdb-glib and evolution-couchdb modules) Tarballs are already published on GNOME's FTP Bugs are right now in Launchpad, but moving them to GNOME's bugzilla as soon as needed Adoption Both modules are included in Ubuntu One service integration in Ubuntu Karmic upcoming release, to provide contacts synchronization between the desktop CouchDB database and the cloud-based services of Ubuntu One. For GNOME 2.29, plans are to add support for calendars and tasks (evolution), and, hopefully, also notes (Tomboy), metadata (tracker), configuration settings (dconf, when adopted, if so) GNOME-ness == Right now, everything is setup like any GNOME project, that is, it uses gettext for translations, and should be accessible (almost no UI involved right now, just a very simple settings widget for evolution to setup CouchDB addressbooks). It is not translated into any language though, but translators should be able to start translating it straight away, since all its ready. Also, couchdb-glib API documentation is missing, but that's one priority task for the GNOME 2.29 cycle, whether the modules are accepted or not. Bugs are in Launchpad, but could be moved to bugzilla.gnome.org pretty easily for the bugsquad. 3.0 readiness = No deprecated libraries or symbols being used. Also, the addition of an online services infrastructure could give 3.0 another major feature to offer to users, apart from what is already planned. Have you considered using the NEPOMUK ontologies (they've spent quite a lot of time developing ways of describing contacts and calendars and such things and from your ML it looks like you are reinventing the wheel). John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30
On Thu, Oct 1, 2009 at 1:12 PM, Rodrigo Moya rodr...@gnome-db.org wrote: On Thu, 2009-10-01 at 12:55 +0100, John Carr wrote: Hi, On Thu, Oct 1, 2009 at 12:42 PM, Rodrigo Moya rodr...@gnome-db.org wrote: Hi Purpose === couchdb-glib is a library to implement the protocol to talk to CouchDB servers (http://couchdb.apache.org), a schema-free, json-based, database of documents, which offers synchronization and replication between several machines. evolution-couchdb is the 1st module to make use of couchdb-glib, to allow contacts from Evolution to be stored in CouchDB databases and replicated/synchronized for free to other CouchDB servers. Target == couchdb-glib for the developer platform evolution-couchdb for the desktop Dependencies couchdb-glib depends on json-glib, libsoup, libuuid and (optionally) libssl (for OAuth authentication) evolution-couchdb depends on couchdb-glib, evolution-data-server and evolution I've not looked at evo-couchdb, is the intention that there would be a local couchdb instance or that it would connect directly to a remote couchdb? evo-couchdb can work with a per-user CouchDB (https://edge.launchpad.net/desktopcouch ) which is what is used for Ubuntu One syncing, with a system-wide CouchDB (http://localhost:5984) or with any remote server you set up. On that server you just need to run a CouchDB instance on a known port, and create an addressbook in Evolution to point to it. The Evolution-couchDB UI shows the 3 options just for the sake of simplicity for the user, but all 3 options are the same, you just need to point it to a URL:port, and evo-couchdb uses the same code to connect to all 3 of them. Of course, the most interesting thing is to be running a local CouchDB, so that it can get synchronized to a remote server, but again, evo-couchdb does not force any specific setup. Another typical setup, I guess, would be to connect evolution to a couchdb server on your home network, and synchronize that with a remote server on your office/whatever. Evo-couchdb can deal with any setup you can think of If there is a local couchdb exepected for the common case then maybe the mozilla js dependency needs a mention. it is not required for evo-couchdb to work, so I don't think it needs any mention, apart from saying that if you want to run a local CouchDB, you need to install CouchDB and all its dependencies. I only brought it up because of the ongoing mozilla vs webkit discussions (and mozilla js vs seed/jscore) and i think the most useful configuration of evo-couchdb does depend on couchdb and hence mozilla js. I'm only so bothered in as much as i really don't want a desktop in the future to need 2 javascript engines and each application depending on 2 or 3 different database engines and so on :] Resource usage == Source code is already in GNOME's git (couchdb-glib and evolution-couchdb modules) Tarballs are already published on GNOME's FTP Bugs are right now in Launchpad, but moving them to GNOME's bugzilla as soon as needed Adoption Both modules are included in Ubuntu One service integration in Ubuntu Karmic upcoming release, to provide contacts synchronization between the desktop CouchDB database and the cloud-based services of Ubuntu One. For GNOME 2.29, plans are to add support for calendars and tasks (evolution), and, hopefully, also notes (Tomboy), metadata (tracker), configuration settings (dconf, when adopted, if so) GNOME-ness == Right now, everything is setup like any GNOME project, that is, it uses gettext for translations, and should be accessible (almost no UI involved right now, just a very simple settings widget for evolution to setup CouchDB addressbooks). It is not translated into any language though, but translators should be able to start translating it straight away, since all its ready. Also, couchdb-glib API documentation is missing, but that's one priority task for the GNOME 2.29 cycle, whether the modules are accepted or not. Bugs are in Launchpad, but could be moved to bugzilla.gnome.org pretty easily for the bugsquad. 3.0 readiness = No deprecated libraries or symbols being used. Also, the addition of an online services infrastructure could give 3.0 another major feature to offer to users, apart from what is already planned. Have you considered using the NEPOMUK ontologies (they've spent quite a lot of time developing ways of describing contacts and calendars and such things and from your ML it looks like you are reinventing the wheel). I talked with you about it, and haven't had time this cycle to look much at it, but yes, it might be interesting to look at using them, or at least integrating easily with tracker's usage of them I know the feeling. We should really sit down and look at this before your home grown ontologies are frozen
Re: Tracker, Zeitgeist, Couchdb...where is the problem ?
On Wed, Aug 19, 2009 at 2:53 PM, Ivan Fradeivan.fr...@gmail.com wrote: Hi, On Wed, Aug 19, 2009 at 2:11 AM, Thomas H.P. Andersen pho...@gmail.com wrote: On Tue, Aug 18, 2009 at 22:48, Matthias Clasenmatthias.cla...@gmail.com wrote: I think this recent discussion about tracker as a gnome module is somewhat backwards. I don't think it is leading us anywhere to talk about ontologies and rdf and events and timelines and metadata stores and kernel apis before we answer the first question: What is the user problem that we are solving here ? Can that be described in a paragraph ? And if it can, is it something that a 'regular' user would recognize as a problem he has on his computer ? The basic problem is to link information and make it available out of the application silos. The desktop is full of data, but there is no way to mix those data. IM messaging, Contacts, Email, are very close to each other but we cannot build a Google wave-like window. The classic search engines (tracker 0.6, beagle) were fighting against tons of formats to reconstruct information. The application knows that some information is a contact, save it in a vcard, tracker reads the vcard and tries to reconstruct the contact. This solution tends to fail: the reconstruction is never complete, and a lot of guess is needed. So the new approach in tracker 0.7 is to offer a common schema, and let the application push the information directly. Skip the file step, so no information is lose in the file roundtrip. What does this mean to the user? That he can see related information everywhere. For instance, take EOG * you could filter by photos sent by... * you could open an IM conversation with the person who sent you the picture * you could have a tag cloud, including your fspot tags * If zeitgeist set relations between photos, it could suggest related documents * In EOG you can ask for photos tagged as GCDS and find local/flickr/facebook results with that tag This could apply also to totem or rhythmbox. s/pictures/songs/ The browser: * Bookmark a page in epiphany, and it is available in firefox. Other example: * Somebody write: Hey, have you take a look to the document i sent you yesterday? and your dashboard shows the last document sent by that contact and his last blog posts. It can show that not because it understand the have you take a look... but because it knows you are talking with a certain contact. I.E. No magic or wonderfull inference: just queries to a well structured database. Right now, all the information is already available somewhere (evo, telepathy, pidgin, ...), but these use cases are impossible to implement. Thanks for this explanation - its one of the best ones i've read :) Once we have the problem scoped out, we need to look at the user experience we want to aim for in solving it. Will it be a single search-for-everything dialog ? A query language ? Tagging everywhere ? The dedicated search window is dead. The applications are the client of this central storage: the application knows what is showing, so knows what can be related with it! After that, it might be possible to evaluate whether tracker, zeitgeist, couchdb or something else can be part of the implementation... Zeitgeist + tracker are complementary (and a nice team together). CouchDB is also a storage but with a different philosophy. The nicest part is the synchronization... but maybe we could wrap tracker in a similar code to allow the online replication. This is just a wild guess. I think its possible - here is a little something i've been hacking up on my train to work for couch pulling from tracker: http://github.com/Jc2k/tracker-replicator/tree/master And i've been talking to Rodrigo - couchdb-glib might make implementing a client of this even easier :) Regards, Ivan John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libgdata as a new desktop module
On Thu, May 7, 2009 at 7:27 AM, Philip Withnall phi...@tecnocode.co.uk wrote: Hi, I would like to propose libgdata as a new desktop module for GNOME 2.28. libgdata is a GLib-based library for accessing online service APIs using the GData protocol — most notably, Google's services. It provides APIs to access the common Google services (at this stage, only Google Calendar, YouTube and Google Contacts; PicasaWeb support is in the works), and has full asynchronous support. You might have already heard a little about it on my blog[1]; a little more information is available on its l.g.o page[2]. libgdata 0.2 was released a few weeks ago, and a 0.3 release will be made in a few more weeks' time. Until version 1.0, there are no guarantees as to API stability, with errors in the API being corrected with each release. libgdata will not introduce any new dependencies; it depends on only: * glib-2.0 = 2.16.3 * libxml-2.0 * gio-2.0 = 2.17.3 * libsoup-2.4 = 2.24.0 It can optionally depend on libsoup-gnome-2.4 for GNOME integration (such as automagic proxy support). libgdata uses GNOME resources exclusively: Bugzilla, git, damned-lies and GNOME FTP. The library is already in use in the Totem YouTube plugin, and I'm in the process of porting evolution-data-server to use libgdata[3]. As a consequence of being used in Totem, the library is already packaged for Fedora 11[4]. As far as community is concerned, libgdata is mostly there. There is full API documentation, and the few strings which can be localised, are. libgdata fits (I think) nicely into the GNOME 3.0 vision, allowing tighter web–desktop integration. It doesn't use any deprecated libraries or API. There were two SoC projects this year which were related to integrating Google services in applications, and I have high hopes that libgdata will be able to help in that area. libgdata is licenced under LGPL 2.1. The project started in January 2009, and has already had two person-years invested in it, according to Ohloh[5]. I suppose this should be taken with a pinch of salt, but it gives the general idea. If libgdata does not make it as a desktop module, for whatever reason, it needs to be listed as an external dependency, due to its use in Totem and upcoming use in evolution-data-server. Regards, Philip Withnall Maintainer of libgdata [1]: http://tecnocode.co.uk/2009/04/07/libgdata/ [2]: http://live.gnome.org/libgdata [3]: http://bugzilla.gnome.org/show_bug.cgi?id=580021 [4]: https://bugzilla.redhat.com/show_bug.cgi?id=493432 [5]: https://www.ohloh.net/p/libgdata ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Awesome :) +1 here. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
Hi, On Mon, May 4, 2009 at 9:38 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: Hi, I was one of the happiest person on this planet the day we moved to git and i can't thanks the people involved enough. Although overall i am pretty happy with the migration, I do have one concern: The policy of disallowing non-fastforward pushes to any branch. I understand that this is good for master and other stable branches, but otoh I think it breaks the usual git workflow for feature branches. I don't think it does break the usual git workflow. See [1] and [2]. In particular: Rebasing is clearly a useful technique, though. Linus does not tell developers not to use it; in fact, he encourages it sometimes. The key rule that was passed down is this: Thou Shalt Not Rebase Trees With History Visible To Others This means: if you're still in the git rebase phase, you don't push it out. If it's not ready, you send patches around, or use private git trees (just as a patch series replacement) that you don't tell the public at large about. git.gnome.org is quite public. There is email and IRC spam and everything. Suppose you could use heuristics to turn that off, but not really a fan of that. I for one want the spam on all my branches (if im still in rebase phase im not pushing to GNOME). I had a little chat with Owen regarding this: == IRC LOG BEGIN== zeenix owen: hi, are we sure about this 'only fastforward for all branches' policy? owen zeenix: Well, if we had a way of figuring out that some branches where feature branches not maintenance branches, then we could conceivablly allow rebasing those branches zeenix: But not sure how to do that. I suppose we could say if there are no numbers in the branch name it's a feature branch, but that would make thigns weird if you had a branch 'bonobo-removal-2' or something zeenix owen: or you could make developer put some specific prefix in the name of feature branches? owen would be a bit ugly if all our branches were named feature-* owen zeenix: feel free to mail suggestions for a policy to gnome-infrastructure zeenix ok, will do ==IRC LOG END== I am sending this mail here cause I thought it might be better to have a discussion on this and so that other developers can speak-up if they (dis)agree. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 John [1] http://lwn.net/Articles/328436/ [2] http://lwn.net/Articles/328438/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: R: git migration - svn:externals
On Thu, Apr 23, 2009 at 12:27 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: On Thu, Apr 23, 2009 at 1:24 PM, Tim-Philipp Müller t@zen.co.uk wrote: On Thu, 2009-04-23 at 12:09 +0200, Jaap A. Haitsma wrote: I think gst-ffmpeg uses this feature. gst-ffmpeg is in git while it uses ffmpeg which is in svn. Not really - gst-ffmpeg just runs svn checkout in autogen.sh, and that's it. We use git submodules in GStreamer though (we have a 'common' submodule for all other modules), but git submodules are still fairly cumbersome to use and I wouldn't recommend them until the git people make them less painful to use, at least not for projects where the submodule reference needs to be updated frequently. This whole idea of sub-modules is just brain-dead so I wouldn't count on git developers fixing that instead of concentrating on features of real importance. If you have some code (or even data) that is needed by more than one of your modules/packages, you either put that common stuff in another module/package and make other packages depend on this or you just bite the bullet and don't mind the redundancy. In some cases you just have to wisely use the combination of both. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 Very much +1. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Move back 2.27.1 one week?
On Wed, Apr 22, 2009 at 5:01 PM, Srinivasa Ragavan sraga...@novell.com wrote: Evolution isn't yet ready to do anything. I heard there are similar modules. Settling with jhbuild w/git, and the entire clone, pro'lly gonna eat lot of time. If its possible, I second this. -Srini. On Wed, 2009-04-22 at 10:50 -0500, Jason D. Clinton wrote: With the outstanding git migration problems (and the resulting inability to jhbuild) perhaps we should postpone 2.27.1 by one week? Can we selectively roll back JHBuild modules that are failing because of broken Git repositories to point at SVN? Seems nicer than breaking jhbuild build? Any individual modules having problems could use a git-mirror (i havent downed the server, yet...) and then use git-format-patch and git-am to migrate when the module is fixed. Alternatively we could try and get SVN access turned back on for broken modules if fixing the problems is going to take any unreasonable length of time. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Adding module descriptions
On Fri, Apr 17, 2009 at 10:08 AM, Ross Burton r...@burtonini.com wrote: On Thu, 2009-04-16 at 16:58 -0400, Owen Taylor wrote: The great migration to git.gnome.org is now underway. Once your module shows up on http://git.gnome.org/cgit/, you'll notice that it is described as: Unnamed repository; edit this file to name it for gitweb. Since you want something better than that, what you are going to do to fix is add a file in the toplevel of your module named: modulename.doap Devil's Pie already had a DOAP file: http://git.gnome.org/cgit/devilspie/tree/devilspie.doap But I still see unnamed repository :/ Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com I think its a post push hook to poke the git module settings and wasnt run as part of the import. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Git day minus 1
On Thu, Apr 16, 2009 at 1:39 PM, Ruben Vermeersch ru...@savanne.be wrote: On Wed, 2009-04-15 at 17:27 -0400, Kristian Høgsberg wrote: Tomorrow, Thursday April 16th, is the big flag day for the GNOME repositories. We've moved over quite a few repositories from SVN, GitHub, freedesktop.org and other places that people have put GNOME git repositories, but tomorrow we finish the migration and move over everything else. We've timed it so that the 2.26.1 release could be finished first, and since that just happened, now is the time to push the big button. Thanks to a lot of sysadmin legwork from Owen, the GNOME git infrastructure is looking great: we have cgit set up on git.gnome.org and the various commit hooks and mailing lists scripts have been setup and tuned. So eh, what does this mean for the svn-commits mailing list? Will git commits end up there? Will we all have to subscribe to a new git-commits list? Can we get migrated automatically? Cheers, Ruben From what i've seen on that list, Git commits already end up there. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Desktop synchronization
On Thu, Apr 2, 2009 at 3:55 PM, Frank Niedermann f...@thelogic.org wrote: Hi, I saw that there are many ideas for the Gnome 3.0 Desktop and I was wondering, if there are also plans for Desktop synchronization? Example: User Joe has a Desktop PC at home with Gnome 3.0 He has some pictures in his home folder from his digital camera. He taggs some of the pictures and has done some editing with gimp. Next day he is at school/work/somewhere with his laptop. Will he see the pictures in his homefolder? Will he see the tags he made on his Desktop PC? Will he see gimp as last used application (not yet started on the laptop)? I think that Desktop synchronization gets more and more important with the features the desktop gets, like tagging documents. Would be very great to have some synchronization with Gnome Desktop, like Apple has with the .Mac accounts. Thanks, Frank -- Theres lots of work going on, but i'm not sure what will be ready for GNOME 3.0. I think the closest GNOME saw to .Mac was http://online.gnome.org, but i think work on this has slowed in favour of the GNOME Shell work. John Stowers and friends continue to work on Conduit which is already an accepted external dependency for GNOME apps wanting to add sync to their part of the desktop. Work is on going for building conduits between the desktop and both online services like Google and ScheduleWorld and mobile devices. It should be in good shape for 2.28, the main blocker is people integrating it - i have some ideas though: Epiphany integration. Visit a service that Conduit supports - Google, Facebook, Box.net and in the future anything with SyncML support like ScheduleWorld - and Epiphany asks you if you would like to set up sync with that services. At the very least you won't have to put any details like usernames in apart from password. Maybe if gnome-keyring is used, even that won't be needed. (Of course, Firefox integration would be needed for those distros that dont encourage Epiphany). Bluetooth pairing integration. When you pair a device you tick a sync checkbox. And paired devices with that flag will be synced to the configured GNOME PIM application. (In the future there is no reason why as i user i shouldnt be able to pick GMail as my default PIM and Conduit would sync phones directly to that, and tracker would index Gmail directly too). There is also Wizbit which is still in very early stages but is concerned with, for desperate want of a better description, all about your personal cloud, or mist. The end goal is to use DVCS type technologies to replicate your data between all your devices, with some emphasis on tracker so that metadata about last used documents (which implies used applications) and tagging data and all the other RDF goodness are also everywhere. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
Anyway, I'd rather add John Carr to the sysadmin team. I plan to make a proposal to switch GNOME to a DVCS where Git works using Johns suggestion. Then other sysadmins[1] can suggest whatever proposal they want. These proposals can be investigated on merit and then a one can be chosen (chosen as in: go ahead and try if this would work, not go ahead blindly; everything must be tested before a cutover). John's idea is a good one but it patently loses on technical merit. As stated by John here, git will only be support in a degraded, bastardized form because he chose bzr as the repository format: http://blogs.gnome.org/johncarr/2008/12/11/dvcs-for-gnome/#comment-172 Are we really going to go back to the days of CVS where file moves aren't supported? A git move operation is simply git rm git add. By that reckoning i'd either not be able to represent any deletes or any adds because of that god damn impaired Bzr file format! Wow, i'd be so eager to share that idea with the community ;) The big deal here is that git uses a heuristic to say Foo is now called Bar (selectively; its not done for speed in some cases). This is not stored anywhere in the file format, git redetermines it (if it wouldnt be too slow to do so). In Bazaar, its stored in the file format. This means merge doesnt have to consider ancestry to know if 2 files are related, it just knows they are. Solution? We simply have to run that heuristic ourselves so that Bazaar knows 2 files are related at import time. Git support is not degraded here, and Bazaar is no worse off than if you had imported a Git project into Bazaar for the first time (basically merge will work, but won't work *as* well in the rename case). I'm not a complete idiot - if it was going to be a degraded, bastardized form of Git I wouldn't waste my time on it. I suppose I might be an evil genius stalling for Bazaar DS9 to be written (sorry for the very bad joke that probably only i get...). It strikes me that this very vocal minority--John and Robert Carr, Karl Lattimer and Rob Taylor (whom are four of the six people I mentioned above)--are potentially delaying even longer what we've wanted for more than two years, now. It is from these same people that came the suggestion that git users were a rapid, vocal minority. Why are we letting them derail this process? This is not my 1st reply. The first one was fully of angry cow :(). Please dont single people out. I'm happy to have a hand wavy discussion with you 1st person, IRL especially so. Also, KL and RT are innocent. As bkor has stated, there are lots of Git users so any implementation will support you, and support you well. That is a requirement. So any talk of my idea is not Git vs Bazaar, its talk of one way we can move forward. So i dont consider it to be derailing. When mentioning my idea, lets stick to technical problems with it rather than trying to undermine anyone who has looked at it and thinks it is sound and doable. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DVCS
On Tue, Oct 28, 2008 at 2:24 PM, Zeeshan Ali Khattak [EMAIL PROTECTED] wrote: Hi everyone! I remember that at GUADEC, we were seriously thinking about migrating to git but the decision was postponed on Mark Shuttleworth's request. It's been some months since that and we are still stuck with SVN. AFAIK both git and bazaar have very strong supporters in our community so the only way I see out of this is: 1. Get someone (known and trusted) to volunteer to set-up and maintain the repository. I think Olav likes bazaar so he would volunteer for that? 2. Assuming that we get volunteers for both the repository types, we simply vote amongst the top 50 contributers (i myself most probably don't count :)) Lets not turn this into yet another bazaar vs. git war cause we already had plenty of that and nothing good comes out of that. I think the vote should be down to the foundation members. The reason i bring this up is: 1. I don't see any way of using git mirrors (don't know of bazaar) in jhbuild setup. Help wanted: http://bugzilla.gnome.org/show_bug.cgi?id=538507 2. I want to move a module from o-hand SVN to gnome SVN while keeping the history intact and seems the only way of achieving that is to wait on bkor to get to import the svn dump. Don't get me wrong, I am not saying bkor is taking very long but I have no way of knowing when would he get time to do it. bkor isnt the only sysadmin, but who are the others and how much do they do.. the whole sysadmin process is not very transparent. Shouldn't it be? I would *love* to help out the sysadmins, maybe even offer them some of my time. Where is it documented on how to be considered as a sysadmin? Even a junior sysadmin that can just set up mailing lists and do svn imports... I hang around #sysadmin but there is only so much i can suggest people try before i have to leave them to the irc gods John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DVCS
On Tue, Oct 28, 2008 at 2:59 PM, Zeeshan Ali (Khattak) [EMAIL PROTECTED] wrote: Hi! On Tue, Oct 28, 2008 at 4:44 PM, Thomas Thurman [EMAIL PROTECTED] wrote: I don't think it's a secret that I like one over the other, but I'd rather either of them than sticking with svn. Same feelings here. 2. Assuming that we get volunteers for both the repository types, we simply vote amongst the top 50 contributers (i myself most probably don't count :)) Why 50? Can't we canvass the whole Foundation? Hm.. don't know, just what came to my mind at the time or writing. :) I am afraid if we go for the whole foundation, people like me who talk more and do little will also get counted and maybe we want to avoid that? -- Regards, Zeeshan Ali Khattak FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Don't put yourself down - the fact is you made it through the foundation membership process.. You've shown the guys that manage that process that your a good GNOMie. The power users matter for sure, but some of their arguments against bazaar have been i dont like python and i cant be arsed to learn a new tool... Any and all foundation members are entitled to a say. Actually, shouldn't all SVN account holders be entitled to a say too... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DVCS
On Tue, Oct 28, 2008 at 4:00 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: Claudio Saavedra wrote: On Tue, 2008-10-28 at 15:10 +, John Carr wrote: Lets not turn this into yet another bazaar vs. git war cause we already had plenty of that and nothing good comes out of that. I think the vote should be down to the foundation members. I actually think that, if any, the vote should be down to the GNOME SVN users. But all of them (or at least those who care enough to vote). Agreed. Only recently active SVN users. Why should past contributors who do not commit anymore decide what DVCS tool *I* use? Claudio behdad Don't forget sysadmins. While not active SVN users, they will have to support whatever you demand.. Pretty sure they should have a say.. Personally, no one is telling me what DVCS tool *I* use. Its like mandating I use emacs for GNOME development. Ain't gonna happen... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DVCS
On Wed, Oct 29, 2008 at 12:30 AM, Ali Sabil [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 1:18 AM, John Carr [EMAIL PROTECTED] wrote: On Tue, Oct 28, 2008 at 4:00 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: Claudio Saavedra wrote: On Tue, 2008-10-28 at 15:10 +, John Carr wrote: Lets not turn this into yet another bazaar vs. git war cause we already had plenty of that and nothing good comes out of that. I think the vote should be down to the foundation members. I actually think that, if any, the vote should be down to the GNOME SVN users. But all of them (or at least those who care enough to vote). Agreed. Only recently active SVN users. Why should past contributors who do not commit anymore decide what DVCS tool *I* use? Claudio behdad Don't forget sysadmins. While not active SVN users, they will have to support whatever you demand.. Pretty sure they should have a say.. Personally, no one is telling me what DVCS tool *I* use. Its like mandating I use emacs for GNOME development. Ain't gonna happen... I have been using bzr-mirror for the past few months happily, thanks to John Carr's work I can pull from either bzr-mirror or directly from svn, and push to svn as if it was a bzr branch. I personally think that keeping svn, and maintaining bzr-mirror, git-mirror, and hopefully an hg-mirror would make everyone happy. All of bzr, hg and git provide a mean to interop with svn, while there is not always a way to interop between the various DRCS that people tend to prefer, so maybe sticking with svn for now would be the right choice ? -- Ali As much as I personally agree with the sentiment, unfortunately git-svn is just not as mature and useful as bzr-svn. While you can just 'bzr push' like we already had bzr.gnome.org all along, git-svn has rules and limitations on what does and doesnt work (and maybe what is and isnt safe to try and do...) John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: conduit branched for 2.24
Hi Gil I pinged [EMAIL PROTECTED] with my original e-mail, but i wasnt a subscriber so it got stuck in a mod queue. Which branch is normally shown on gnome-extras? If its normally a stable branch, then gnome-2-24, otherwise trunk... John On Sat, Sep 6, 2008 at 5:09 PM, Gil Forcada [EMAIL PROTECTED] wrote: Hi, If you want to have stats for that branch make sure to ping gnome-i18n :) I have added it, which branch you want to see in damned-lies gnome-extras page? Cheers, El dv 05 de 09 de 2008 a les 11:09 +0100, en/na John Carr va escriure: Not sure if it needs announcing as we're only an blessed dep, but conduit branched for 2.24. John ___ gnome-i18n mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gnome-i18n -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
conduit branched for 2.24
Not sure if it needs announcing as we're only an blessed dep, but conduit branched for 2.24. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: conduit
On Wed, Jul 30, 2008 at 12:37 PM, Willie Walker [EMAIL PROTECTED] wrote: From Li Yuan regarding a11y: Accessibility is a problem for conduit. The GUI is simple, but the left tree view doesn't support keyboard navigation well. Also one has to drag some items to the right sync area, there is no way to do this by keyboard. And the sync area is not accessible. I suspect accessibility work is need by goocanvas. See: http://bugzilla.gnome.org/show_bug.cgi?id=545429 http://bugzilla.gnome.org/show_bug.cgi?id=545430 http://bugzilla.gnome.org/show_bug.cgi?id=545431 Li I was asked to give an update on a11y. One of the above bugs has now been closed as invalid (The treeview supports the standard keyboard operations). I've been doing some work on 545431 and think that i'd need to patch goocanvas, pygoocanvas and pygtk to provide the proper experience. I hope that the pygtk patching will be enough to close the bug, though. See [1] for more information. We've talked a little about 545430. It should follow shortly after some other usability tweaks. [1] http://blogs.gnome.org/johncarr/2008/08/04/conduit-and-accessibility/ John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: conduit
On Tue, Jul 29, 2008 at 11:21 AM, John Stowers [EMAIL PROTECTED] wrote: On Tue, 2008-07-29 at 11:24 +0200, Murray Cumming wrote: On Mon, 2008-07-28 at 00:32 +0200, Vincent Untz wrote: Homepage: http://www.conduit-project.org svn/git/bzr/...: http://svn.gnome.org/viewvc/conduit/ Proposal on d-d-l: http://mail.gnome.org/archives/desktop-devel-list/2008-March/msg00320.html License: ??? (GPLv2 or later?) Short description: == Conduit is a synchronization architecture for the GNOME desktop. It provides an intuitive GUI for synchronizing things and a DBus interface for external applications to do the same. Surely any proposed application should be much clearer about what it will allow users to do. What can I realistically expect to sync with what? Are we talking about syncing multiple desktops, or syncing information between the desktop and phones/PDAs. For a good overview, written better than I could, please check out the lifehacker article http://lifehacker.com/398775/sync-and-back-up-your-data-with-conduit-for-linux And also, the presentation I gave at GUADEC is pretty informative http://files.conduit-project.org/Conduit%20-%20GUADEC%202008.pdf How easy is it to do this for any particular specific cases, such as syncing a Palm with a desktop PC (With Evolution, hopefully), or syncing the contacts on my mobile phone, or with my N810? Palm isnt supported. Thanks to someone i met at LRL, we should have a couple of palms to work on replacing gnome-pilot be august 15th so palm support won't be far away, but will be after the next stable release. Windows Mobile 2003 should be easy, and we have the hardware for testing. Will follow WM5 polishing and Palm work. Windows mobile 5/6 support is OK, and getting better. Nokia phone support (via gnome-phone-manager is being worked on ATM) Nokia nxxx support is pretty good. I did have a blog post from a year ago showing off PC to PC sync, but my migration to blogs.gnome.org seems to have killed the video... Our strength and historical focus has been sync to online services from GNOME apps. Our current focus is on mobile devices. We have two SOC projects, SyncML support, and iPod support. Also, shouldn't this be integrated into particular applications? Shouldn't Evolution have a sync menu item, replacing it's current awful gnome-pilot synchronization feature. Personally, I want to plug in my device and have my desktop say hey, wanna sync this?. The next time I plug it in, i just want it to sync. If i leave it plugged in, I want things to sync in response to change events in the applications we are syncing. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: conduit
On Tue, Jul 29, 2008 at 1:20 PM, Dave Neary [EMAIL PROTECTED] wrote: Hi, Bastien Nocera wrote: On Tue, 2008-07-29 at 11:24 +0200, Murray Cumming wrote: snip Also, shouldn't this be integrated into particular applications? Shouldn't Evolution have a sync menu item, replacing it's current awful gnome-pilot synchronization feature. It might be awful but it's working. Given that I've never managed to get sync working with my new phone, I thought I'd give this a try again give a return on experience... When I plug my phone over USB, FSpot starts offers to import photos from the phone. Skip that... start Evo and try do a sync. http://www.flickr.com/photos/bolsh/2713756602/in/photostream/ GNOME Pilot starts up a wizard, detecting that this is the first time I'm setting up a sync source. http://www.flickr.com/photos/bolsh/2712943917/in/photostream/ I changed Cradle to Phone, and selected USB for sync. I guessed the device would be usb:, but really I was surprised I needed to. http://www.flickr.com/photos/bolsh/2713756782/in/photostream/ I need to configure an owner name PDA ID? I have no idea what these are for... Oh, well, assume sensible defaults... http://www.flickr.com/photos/bolsh/2713756836/in/photostream/ I have no HotSync button, my phone is plugged in, but undetected, and there is no way to complete the registration of the sync source. Am I doing something wrong, running an unsupported phone (is there a list), or does this stuff just not work as well as I'd have hoped? I can't tell :-) What kind of device do you have? Conduit can sync Evolution, but it doesn't integrate into Evolution yet. (So your screenshots are nothing to do with us :-) I can assure you that when we assimilate gnome-pilot you won't have to set all those options. We haven't yet, though, so if you do have a palm based device you will probably have to wait for 2.26. As for a list of devices, the best i can manage is to say anything on this list that runs WM5 or above (support for below WM5 isn't hard, though). http://www.geekzone.co.nz/smartdevices.asp or the N800/N810 or iPods. We are working with/on phonemgr to support any of the devices on this list: http://wiki.gnokii.org/index.php/Config I can point you to the branches of Conduit and phonemgr to try this out, but we are crashing somewhere in gnokii/phonemgr right now. I don't have a device to test this, so i'm dependant on Rob to not be busy and wanting to get his new phone to work (trust me when i say its mainly the busy thats getting in the way). And finally, John is working on SyncML. Which will potentially mean more devices than we can shake a stick at. I'm all for thinking positive, but the uniform feedback I've had when talking to people is that syncing smartphones on Linux needs a lot of work. Cheers, Dave. It's not easy, but I think its doable in a release cycle given a suitable array of test devices. The code to support Windows, Palm, Nokia, Sony, Motorola and any outlying SyncML devices is all there. Someone just needs to sit down and integrate it. Which is what we are doing. (Donating devices that arent yet supported is a big help, and thanks to people doing just that I can finally start on sorting out gnome-pilot..) (Sorry for being an outlier in your dataset :-) John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: conduit
On Tue, Jul 29, 2008 at 12:13 PM, Frej Soya [EMAIL PROTECTED] wrote: John Carr john.carr at unrouted.co.uk writes: Also, shouldn't this be integrated into particular applications? Shouldn't Evolution have a sync menu item, replacing it's current awful gnome-pilot synchronization feature. Personally, I want to plug in my device and have my desktop say hey, wanna sync this?. The next time I plug it in, i just want it to sync. If i leave it plugged in, I want things to sync in response to change events in the applications we are syncing.John Is that possible with bluetooth devices? For local sync i assume (well it's pure guessing) that bluetooth would be the major use case. If it's GUI button+bluetooth vs. physical insertion+auto detection, i actually prefer a button. I really don't think it's horrible to have a sync button, especially when cool wireless hardware saves me from the annnoying cable. With bluetooth, the 'always on case' consumes power on two portable devices (laptop+phone)? Ofcourse my point of view is based on my (possible) use of conduit ;). That's calendar and contacts. I support people using SynCE (the software for using all Windows Mobile devices on Linux/*BSD) and by far the majority are using cable based connections. Myself included. I tend to have the cable with me for charging, and its easier to plug in my phone and have stuff happen then mess around establishing a bluetooth connection. But we can support both use cases. And I know some people who are on desktops and want their machine to scan for their phone and sync in the background if its available. We can do that too. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: conduit
On Tue, Jul 29, 2008 at 2:19 PM, Dave Neary [EMAIL PROTECTED] wrote: Hi John, John Carr wrote: Am I doing something wrong, running an unsupported phone (is there a list), or does this stuff just not work as well as I'd have hoped? I can't tell :-) What kind of device do you have? Conduit can sync Evolution, but it doesn't integrate into Evolution yet. (So your screenshots are nothing to do with us :-) I can assure you that when we assimilate gnome-pilot you won't have to set all those options. We haven't yet, though, so if you do have a palm based device you will probably have to wait for 2.26. I was replying to Bastien, who said that gnome-pilot worked. I don't have Conduit installed, the screenies are from the GNOME Pilot assistant. My phone is a W910i. Cheers, Dave. My apologies then, I took your e-mail as a bit of a (friendly) poke at us because we don't yet integrate into the Evolution UI. Hopefully your phone will sync with Conduit /soon/ as its a SyncML device (summer of code FTW). If you want to help us out, it would be nice to know what HAL sees when you connect it by USB etc. If its a serial device, it will need PPPing and lets hope SE stopped using mrouter or it will get icky for all involved :) (If you want to e-mail me and john off-list, or mail conduit-list or pop into #conduit some time...) John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: conduit
In future there may be additional reasons to have conduit running all the time, such as 'always up to date' sync (only our gconf sync uses this ATM, IIRC). The Tomboy and Folder plugins support Always Up To Date, and in a couple of days the windows mobile stuff will too. Evolution could, but the bindings need more love, IIRC. F-spot may. We implemented the dbus support in F-spot, so i suspect its possible. (For non conduit people, Always Up To Date is when an application tells conduit to sync because a change occurred. These are always in direct response to a change and never done on a timer. Polling for the fail). John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External Deps: Minimal Python dependency
2008/7/22 Damien Grassart [EMAIL PROTECTED]: On Tue, Jul 22, 2008 at 11:01 AM, Olav Vitters [EMAIL PROTECTED] wrote: What distributions have Python 2.5 and what has changed since the last time this came up? I don't know what has changed but Arch, Fedora, Mandriva, openSUSE, Slackware, and Ubuntu currently use Python 2.5, while many others do not (most notably RHEL and Debian). Thanks, -Damien Debian Lenny has a release goal of Make all packages support python2.5 as standard python version. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Future of GNOME: Semantics
On Sat, Jun 14, 2008 at 9:11 PM, Anders Feder [EMAIL PROTECTED] wrote: Olav, Thanks for your reply. I figured that people had read enough shiny use cases, so I tried to keep those to a minimum, but sure. Let's say you use Evolution's address book to manage all your contacts and you just bought a new smartphone which only supports a proprietary address book format. You want to move your contacts to the new phone - what do you do? Conduit has knowledge of which format is used by the phone, but has no way to convert the data. This made me smile. I've just written the transport stuff needed for syncing Windows Mobile 5/6 with Conduit, but I need to convert AirSync XML to VCard and back before i'm finished. Today, chances are that you will have to do something like exporting the Evolution address book to the .vcf (vCard) format and then searching for and downloading an application which is able to convert from .vcf to the proprietary format and then finally move over the converted file to the phone. Most likely, coming up with the steps involved in this task is either too complex or too boring for many users. I agree that writing things to convert to and from vCard, iCal and others is the boring part of Conduit :-D If you can solve this problem for me I will buy you beer. Now let's say that Evolution store its address book in the NEPOMUK Contact Ontology (NCO) format in a central RDF repository and your new phone support the Friend-of-a-Friend (FOAF) format. You do a query for your Evolution contacts in Conduit and request them to be moved to the phone. Conduit (or a lower level component) detects that the source and destination formats differ, automatically search the Web for a matching ontology alignment, map the NCO contacts into FOAF and move them to the phone. RDF can automate many such processes, but a few components would be required (or at least be very handy) at the system level such as a central RDF repository and an ontology mapping service. One problem that you've skipped over is how Conduit learned to speak to the device in the first place. In this case i've written glue to link SynCE and Conduit, i would surely ship an AirSync ontology with Conduit, or get one shipped with SynCE, rather than depend on internet access to dynamically look one up? I think this might be nice for the formats and conversions problem, but it doesn't do anything for the transport problem. A generic dbus interface that we could badger applications to implement, or implement our selves via addins, would mean applications like Conduit could benefit without transport glue needing writing specifically for it. That combined with your solution for format conversion would be awesome. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why do GNOMEdevelopers almost exclusively use git mirrors and for example not bzr mirrors
On Tue, Apr 8, 2008 at 11:08 AM, Olav Vitters [EMAIL PROTECTED] wrote: On Tue, Apr 08, 2008 at 08:14:50AM +0100, Ross Burton wrote: On Tue, 2008-04-08 at 08:35 +0200, Jaap A. Haitsma wrote: I was just wondering why many GNOME developers are using git mirror and for example not a bzr mirror? If I for example read http://live.gnome.org/DistributedSCM I have the feeling that bzr would also be a very good fit. However I haven't seen any gnome.org project in a bzr mirror while of many projects there exists git mirrors. I've been talking with Elijah to determine what is needed in a DSCM. Basically, Bzr should be enhanced/improved to have branches in one checkout directory. For some reason this is important (for real developers.. not me:). E.g. DSCM will likely mean lots of small (private) branches; loads more than with a central system. Like this? http://bazaar-vcs.org/SharedRepositoryTutorial From a blog post 2 years ago: One of the new features comming up in the next release of bzr is support for shared repositories. This provides a way to reduce disk space needed to store multiple related branches. http://blogs.gnome.org/jamesh/2006/04/23/repositories-in-bzr/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Tue, 2007-09-18 at 18:15 -0400, Behdad Esfahbod wrote: On Sun, 2007-09-16 at 19:11 +0100, John Carr wrote: On Sun, 2007-09-16 at 12:27 -0400, Behdad Esfahbod wrote: On Sun, 2007-09-16 at 09:10 +0100, John Carr wrote: On Sat, 2007-09-15 at 18:26 -0400, Behdad Esfahbod wrote: On Fri, 2007-09-14 at 21:31 +0200, Ali Sabil wrote: I am wondering why discussion is continuing in the Git vs SVN (was: Can we improve things?) thread, why the discussion is not happening here instead ?! I don't want to offend anyone (so take it lightly), but I am afraid that many of us are subject to a Confirmation bias ... Can't we just continue the discussion in this thread comparing svn to DRCS in general before deciding on which DRCS would be the most appropriate to use within the GNOME project ? Because you can't talk about some abstract concept. I can't imagine anyone having any remotely legitimate reason to discuss that DSCM systems are not good for GNOME. This is simply a corollary of the fact that DSCMs provide all functionality that the SCSMs do. So, theoretically, you don't lose anything, and gain some. How do you set up a master repository with GIT/BZR? Generally it seems to involve pushing over ssh/sftp? Does that integrate with GNOME accounts? Does letting people push mean they could push other crap and hurt the repo? Or have they both gained daemons? Do they have logins that integrate with gnome accounts? Can one daemon handle multiple repos? These are all no problem at all. See fd.o for example. We are already using ssh with SVN. It's the same with git. How do you see the workflow working though. This isn't simply s/svn/git/. Are you looking to implement centralised VCS powered by GIT, in effect giving you SVN but with offline/merge powers? Or do you want something else out of it. Depends on how you look at it. From far, yes, it looks like just s/svn/git, but from near, you see developers hosting their own trees for various experimental features, etc. This is how kernel works, and how cairo and other fd.o modules work. This is the central cairo repo for example: git+ssh://git.cairographics.org/git/cairo I was more interested in whether this was a case of upgrading the existing GNOME 'way', or reinventing it. For example, in the linux case (as far as i can tell) the workflow is based around the mailing list, a branch each for the core devs and then the Linus branch. It's this gatekeeper approach which I would have been most concerned about in GNOME. From your description, i take it as an upgrade to a fixed SVN with better branches. If we are still using the same accounts infrastructure, then this does nothing to improve the situation RE: new accounts. Which was the whole starting point of this discussion. (You'll probably argue that the win here is that people can maintain local branches to work from if we move to git, but git-svn and bzr-svn don't rule it out either do they?) git-svn and bzr-svn are broken. They are good to get some benefits of git/bzr with svn, but shouldn't be thought of as a long-term plan. You have to flatten all the 20 micro-commits you made before pushing a branch out to SVN, and that undoes all the nice properties of micro-commits and git. Next time you track a bug down to that commit good luck figuring out what's going on... I can't speak for git-svn. But bzr-svn is certainly not that broken. I branched earlier and made a couple of bug fixes on the train. On returning i did bzr push. The fixes arrived in the parent svn tree as individual commits. (Also, from what I am told I could publish my branch somewhere (not SVN) and someone could merge my changes into their branch of the parent SVN. So I could pull John S's work into my branch before either set of work is ready for trunk. Basically, it goes to extreme lengths to ensure that a remote SVN branch is like a remote BZR branch. On a related note, they are even working on exposing an SVN server that pushes commits to a BZR backend). Perhaps a legitimate reason is that moving to a DSCM won't be a benefit to everyone, yet everyone will have to learn another set of tools. Even just last month someone didnt know how to link to a file in SVN. And in order to make happy The GIT Crowd (and piss off all the people that just want to get on with their project) a sugar load of infrastructure needs to be tossed away. Who was that someone? Lets say we install a web application for translators. Who else can't be bothered to learn the new tool? If they can't, they can always submit patches. It was on DDL, not too long back. And he wasn't alone. I just decided to look at some git notes on kernel.org [1]. One of the first things it advised me (in its 20 commands or so version) that i
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Sat, 2007-09-15 at 18:26 -0400, Behdad Esfahbod wrote: On Fri, 2007-09-14 at 21:31 +0200, Ali Sabil wrote: I am wondering why discussion is continuing in the Git vs SVN (was: Can we improve things?) thread, why the discussion is not happening here instead ?! I don't want to offend anyone (so take it lightly), but I am afraid that many of us are subject to a Confirmation bias ... Can't we just continue the discussion in this thread comparing svn to DRCS in general before deciding on which DRCS would be the most appropriate to use within the GNOME project ? Because you can't talk about some abstract concept. I can't imagine anyone having any remotely legitimate reason to discuss that DSCM systems are not good for GNOME. This is simply a corollary of the fact that DSCMs provide all functionality that the SCSMs do. So, theoretically, you don't lose anything, and gain some. How do you set up a master repository with GIT/BZR? Generally it seems to involve pushing over ssh/sftp? Does that integrate with GNOME accounts? Does letting people push mean they could push other crap and hurt the repo? Or have they both gained daemons? Do they have logins that integrate with gnome accounts? Can one daemon handle multiple repos? Perhaps a legitimate reason is that moving to a DSCM won't be a benefit to everyone, yet everyone will have to learn another set of tools. Even just last month someone didnt know how to link to a file in SVN. And in order to make happy The GIT Crowd (and piss off all the people that just want to get on with their project) a sugar load of infrastructure needs to be tossed away. Does CIA.vc have bzr/git support? I guess a few GNOME projects must use it as GNOME is the third most active project today. How does buildbot work with bzr/git? The project looks a bit stalled, but the GNOME buildbot was a great idea that I was hoping to see gain ground. In practice however, git is too hard and confusing to learn. *That* is a reason against this specific DSCM system. This is the reason i've been using bzr-svn. Its svn with benefits style suits me very well. The fact is, i'm happy with svn until i'm stranded without an internet connection, thats with bzr steps in. And its brilliant. I am also afraid that we might be just becoming nothing more but geek fashion addicts trying to follow the latest RCS tendency without really building solid and constructive arguments ! I was going to be offended, but you warned :). Now that most probably means that you don't hack on the more crowded projects that much... Many Gtk+ developers for example could not have been as productive as they are right now if it wasn't for git-svn. And that's only a half-arsed solution. Again, its ok to say something is crap, but please tell us why! SVN SUCKS!! and GIT FTW!! aren't very compelling reasons. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Sun, 2007-09-16 at 09:42 +0200, Vincent Untz wrote: Le samedi 15 septembre 2007, à 21:44 -0400, Behdad Esfahbod a écrit : Ok, lets be fair: most people who care about hacking on GNOME already know git, why should other options be selected? I don't think it is fair to state this. A lot of people certainly care about hacking on GNOME and don't know git (and don't care about it). [sorry, this doesn't add anything useful to the debate] Vincent I agree. Though this is something important to say Vincent, as its apparently not clear to everyone. It's wholly wrong to declare that most want GIT without backing it up. Without some figures, a survey or more people joining in the GIT++ corner, its just fanboyism. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Both Git and Bzr have svn interoperability. Are these implementations so broken as to not be useable by the DSCM-desiring people? I've had a quick play with bzr-svn and it feels like quite a natural step up from svn. It has the advantage that people who want DSCM get it, it doesn't involve learning lots of new commands (very similar to svn commands wise). And of course, for those of us that don't need it, we don't have to use it. Finally, no infrastructure changes are needed to take advantge of it either. I presume the same is true with git-svn, thus avoiding git/bzr wars? Just my 2p John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 20:47 +0100, Gustavo J. A. M. Carneiro wrote: On Wed, 2007-09-12 at 20:28 +0100, John Carr wrote: On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Both Git and Bzr have svn interoperability. Are these implementations so broken as to not be useable by the DSCM-desiring people? I've had a quick play with bzr-svn and it feels like quite a natural step up from svn. It has the advantage that people who want DSCM get it, it doesn't involve learning lots of new commands (very similar to svn commands wise). And of course, for those of us that don't need it, we don't have to use it. Finally, no infrastructure changes are needed to take advantge of it either. I presume the same is true with git-svn, thus avoiding git/bzr wars? If a developer wants to use e.g. bzr, he can use it behind the scenes, but: 1. With a manually written ChangeLog file, you can't easily branch and merge even with bzr, or you can but every time you merge you'll get conflicts in the ChangeLog file; 2. Unless the bzr branch is official, you can't get rid the manually written ChangeLog file because you have to support svn users who can't easily do micro commits (due to network lag) thus need a ChangeLog file to work around this limitation; 3. It is unthinkable to make a bzr branch official branch for a project unless it's hosted in a GNOME server; 4. To host a bzr branch in a GNOME server you need official support from the GNOME admin team because: a) hosting on www.gnome.org/~user/ ? Nah.. www.gnome.org is not appropriate for that, or so they tell us; b) You need to allow multiple commiters to the same user-neutral branch; c) you need to run a bzr smart server on the server side or else network performance is going to be rather bad. Bottom line, unless GNOME supports a DSCM, it kind of works, but things will never go very smoothly and developers will not take full advantage of the DSCM. I don't see the problem with creating your Changelog and attaching it to the revision log with svn ci -F SomeChangelogFile. With this you can build up a revision log message as you go. And your changelog data is now in the revision log (where it belongs IMHO) and doesn't conflict anymore. Pretty easy. Once the Changelog is removed, or no longer updated, this argument goes away. So what other problems are there with bzr-svn / git-svn? John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 21:58 +0100, Gustavo J. A. M. Carneiro wrote: On Wed, 2007-09-12 at 21:40 +0100, John Carr wrote: On Wed, 2007-09-12 at 20:47 +0100, Gustavo J. A. M. Carneiro wrote: On Wed, 2007-09-12 at 20:28 +0100, John Carr wrote: On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Both Git and Bzr have svn interoperability. Are these implementations so broken as to not be useable by the DSCM-desiring people? I've had a quick play with bzr-svn and it feels like quite a natural step up from svn. It has the advantage that people who want DSCM get it, it doesn't involve learning lots of new commands (very similar to svn commands wise). And of course, for those of us that don't need it, we don't have to use it. Finally, no infrastructure changes are needed to take advantge of it either. I presume the same is true with git-svn, thus avoiding git/bzr wars? If a developer wants to use e.g. bzr, he can use it behind the scenes, but: 1. With a manually written ChangeLog file, you can't easily branch and merge even with bzr, or you can but every time you merge you'll get conflicts in the ChangeLog file; 2. Unless the bzr branch is official, you can't get rid the manually written ChangeLog file because you have to support svn users who can't easily do micro commits (due to network lag) thus need a ChangeLog file to work around this limitation; 3. It is unthinkable to make a bzr branch official branch for a project unless it's hosted in a GNOME server; 4. To host a bzr branch in a GNOME server you need official support from the GNOME admin team because: a) hosting on www.gnome.org/~user/ ? Nah.. www.gnome.org is not appropriate for that, or so they tell us; b) You need to allow multiple commiters to the same user-neutral branch; c) you need to run a bzr smart server on the server side or else network performance is going to be rather bad. Bottom line, unless GNOME supports a DSCM, it kind of works, but things will never go very smoothly and developers will not take full advantage of the DSCM. I don't see the problem with creating your Changelog and attaching it to the revision log with svn ci -F SomeChangelogFile. With this you can build up a revision log message as you go. And your changelog data is now in the revision log (where it belongs IMHO) and doesn't conflict anymore. Pretty easy. It's not the same. You don't want your ChangeLog messages to have bulleted items including a list of changed files, because if you do that then when you generate a full ChangeLog from the stored commit messages things will appear all unaligned. Your changelog text file will be intact in each revision log node. svn can give the log in XML format, meaning that you can style it how the heck you please. This could easily be an identity type transformation that just put the changelog messages in order and dumped them out without touching the format of the actual text. Once the Changelog is removed, or no longer updated, this argument goes away. Like I tried to explain, no maintainer will want to give up on manually written ChangeLog files because: 1- bundling lots of changes in a single commit log message will make the generated changelog look really bad; 2- not bundling lots of changes in a single commit log message implies making lots small commits (i call it micro commits), which is very slow with subversion due to network roundtrips. But wait, if they aren't going to give up on manually written ChangeLogs, won't merge problems still apply? I thought
Re: Online Desktop, Tomboy, and user storage
Some more thoughts, now that i've slept. So currently the case study is for Tomboy syncing data to an OGO web notes application with first class support for tomboy (i.e. not data loss due to formatting getting stripped, and also making use of metadata from Tomboy such as tags). In this limited case study I have no problems with using Tomboys own sync. Given Conduit's still somewhat an external entity it wouldn't make sense for this case study. However, what next? Safe to say the Online Gnome experience won't stop at notes. I would expect that Contacts or Events would be the next logical kinds of data that would be synced to the OGO platform, or maybe Bookmarks. I think it would be a little mad to implement a sync engine and conflict resolution in Epiphany, Evolution, Firefox, Thunderbird, Sunbird or whatever the user happened to be using. So while its outside Havoc's initial case study this is surely exactly where Conduit steps in. We provide desktop wide sync smarts for all these applications and OGO. Now as I've said bookmarks are on their way. Evolution support for Contacts, Events, Notes and Tasks is there. We will be supporting the OGO APIs. (As an aside, It's worth saying that if the Facebook API wasn't over-protective with contact data then Conduit would already implement the Joe changed his mobile number on Facebook and I want my address book updating use case. It would have taken about 10 minutes. And have worked with Evolution, iPod address book, Gmail contacts, and would have worked with new contact plugins in the future.) So with that said, the support i'm asking for is for someone working on OGO for things other than tomboy notes to say yes, that sounds like a reasonable approach.. when we get to these we'll help to evolve Conduit for this instead of rolling our own. Does that sound reasonable? Slight change in topic Now this morning I woke up. Maybe its only having 3 hours sleep, but I started to wonder how Conduit's DataProvider model could be extended. I'm not talking just about sync anymore. The DataProvider model currently supports a change signal. This is fired when any change is detected and says hey, you might want to sync now. Typically this signal comes from something like GnomeVFS telling it which file changed (in the future, it will get a Note blah added signal from Tomboy). This signal is a bit pants at the moment, but what if it was actually fired and said Data ABC was added, Data DEF was removed (Giving the UID and event type at the least). Now rather than Conduit blindly initializing a full sync it can just sync that single piece of data! This is quite cool from a dev point of view, and excellent for always up to date. Eh, its even a win on power saving as we don't have to do all the get_changes crap! Now if an individual conduit has been unavailable for a while (NetworkManager says no network, but now its back) then Conduit can issue a get_changes type sync to fetch everything up to date.. Then use the new signal to keep them up to date. Also think of a turbo charged version of our current network sync, as soon as you edit a note it will appear practically instantly on the other Tomboy instance (ok, ok it would have anyway.. but watching your notes just appear on the 2nd machine is exciting!! and it does save the get_changes over network wasting time). Right now some of you are probably thinking, you're just boring me with an implementation detail! But think about it, if we take this API and also expose it over dbus suddenly apps built on Conduit aren't just about sync. I'm going to presume for a minute that we can do PUSH from OGO. The Conduit API could be used to set trivial watches, not just on OGO but any dataprovider. I'm trying to think of a simple example... How about notifications when something of interest happens? Conduit might already have a friends photos dataprovider that gets the change signals from OGO... Or perhaps Gimmie and BigBoard could benefit. They can use get_all to get the current status of various bits of data they are interested in and listen on the changed signal to have their GUIs kept up to date. Depending on how nice we can get the Conduit UI the code needed in any app to grab and keep data up to date seems quite trivial? I suggest this as a way to not have multiple implementations of the same basic access layer. App's like cheese could directly enumerate available dataproviders to figure out where photos can be pushed. Does providing access to this part of our framework seem useful to anyone besides me? :) Or do I need to catch up on my sleep! My problem is just a general worry that more and more apps will go do the roll there own path when Conduit could help, even in the case of Cheese which is looking to add Flickr support. You have to be on people's radar so they're aware of what you offer. I have been following Conduit because I think it's cool and has a lot to offer the project, but I don't know how many other
Re: Online Desktop, Tomboy, and user storage
Hi everyone This is my third attempt at this e-mail - it's hard not to waffle or repeat myself! It's getting late now so my English may have degraded into nonsensical babble :D The purpose of this e-mail is to consider Conduit as part of the Tomboy case study. How can Conduit help deliver Tomboy online. What benefits does it bring, what disadvantages. What would be the architecture and so forth. Hopefully I will convince you that sync can be generic and that Conduit doesn't care whether its dealing with a data store or something that understands what that data is. That's really a separate issue completely to Conduit and generic sync logic. Conduit is really split in to several parts. Firstly we have a collection of dataproviders. Dataproviders are the application specific parts. No one likes having a common interface, that would be easy and boring, so DP's map everyone's home grown API's onto an established baseline. For easy reference, the basic API is: get_all() - return a list of UID's (think ls) get(uid) - returns an object put(uid, obj) - returns a uid delete(uid) And object needs a unique id, an hash (so we can tell if its changed), and data to sync! An hash could just be the last modified time or a serial/revision number. With this the next layer of Conduit can actually sync two DP's together. It doesn't matter what they are, local or remote or a device. The important thing is the format of the data. Now in some cases this means conversion, but Tomboy Online can be built to use Tomboy's format natively. So no format conversion. We also provide some infrastructure for notifications. These allow a DP to say hey i've got new data to sync!!. DP's can be made available dynamically... This means they appear in response to system events - be it avahi or HAL. This is especially useful in sync GUIs but its available to any app that cares over Dbus. The Conduit GUI is really a pretty thing on top of our core code. If we have a wizard to turn on Tomboy Online out of the box the user might not even see the Conduit GUI. Hopefully it should already be clear how this fits in with the online tomboy notes: * We commit to enabling the automatic background sync feature, which in the scheme of things is quite trivial. It's already partly implemented. When thats done, the experience then becomes pretty darn seamless for the user. * Tomboy remains pretty much unchanged (work to have change notifications from tomboy are underway anyway - its something Sandy already offered to implement for us). * Conduit gains a dataprovider plugin that can sync notes to online.gnome.org through whatever protocol you suggest. This protocol will have to update the Tomboy online data model from the server end. (This may relate to (1) and (3) in your original e-mail. I must be missing part of the ogo stack because I don't see a problem there. Somehow we need to pass the data to the server - WebDAV, REST, direct database access. It doesn't matter. But that doesn't mean that the server can't understand the data. I can send it a file through WebDAV and it can be processed and stored in a DB, or whatever suits the application. So i'm sure i must be missing your point when it comes to (1) and (3)?) * Hopefully the server API will use something like http://brbx.com/orbited so that updates at the server end can appear locally immediately. I could be wrong but I don't think (2a) is possible with a PUSH feature like im suggesting here. (Though it is possible if using Conduit). * For free, Evolution Memos can be put on Tomboy online. The same codepaths allow devices to sync and peer 2 peer without needing separate interfaces. I think an important thing here is that some people won't want online.gnome.org. Personally, i might be tempted to use Conduit to sync them to an SSH account or a password protected area of a server I control. By integrating Conduit people have that choice, and at the same time we don't waste time on multiple sync implementations. I'm not saying Conduit is perfect, but i'm sure people we've worked with will back me up when I say that we will work to resolve any issues we encounter. In closing, I wanted to point out that Tomboy didn't implement its own sync because of Tomboy specific logic. It implemented it's own sync because it was highly desired by GNOME users and yet neither Conduit or OpenSync are first class citizens in the GNOME desktop.. This made reuse something of a no-no (this is documented online, and Sandy or Boyd.. correct me if I'm wrong there...) Apologies if i've glossed over anything there. I'm trying to keep it concise, and i've failed. I've already spent well over 3 hours on my response :-) If something doesn't add up i've probably over-simplified some aspect or completely forgotten about it. Tell me off and i'll try again :-) John C ( Sorry if i put you to sleep ;) ) ___ desktop-devel-list mailing list
Re: Online Desktop, Tomboy, and user storage
Hi, OK, since my last mail was too long ;-) The issue here is very simple. I have the existing Tomboy local data store (NoteManager) which is C# objects, and I have some server-side app logic (the Java process on online.gnome.org) which has its own way of looking at data (Java objects). *As an implementation detail of a larger project* I need those two trees of C# and Java objects to be in sync. If something like DAV gets involved, it's just as a protocol; it would be one way to eventually end up with Java objects in the server app. So let's just ignore DAV vs. XMPP for a minute. OK. I think that is an excellent summary of many rather large scary e-mails :-) Tomboy has a SyncManager thing, which knows how to sync the NoteManager to my implementation of a SyncServer interface that sends stuff to my server app. The thing I'm planning is to implement SyncServer so it somehow gets stuff to my Java server, and then I'm coding a server-side app. For me, SyncServer is just a simple way to hook in to Tomboy. So, concretely how does Conduit affect what I am doing, meaning, which code I'm thinking of writing in Tomboy would I write differently? As i've tried to say, Conduit is what Tomboy should have used for sync. I think I see *another* e-mail where I can explain this better :-) I don't know how to explain it. Conduit is meant to be desktop wide sync. Unfortunately Tomboy had to roll their own this release cycle and we were stuck on the outside of the GNOME wall were we couldn't really help. This is a bit of a setback for Conduit adoption! But if average users want to sync in this release cycle Conduit is perhaps still the best option, which is why Sandy was so helpful to us. (Thanks :D) I'm going to go to the other e-mail now, there are more specific questions I might actually be able to answer :-) John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop, Tomboy, and user storage
Hi Guys I'm one of the Conduit developers and I'd just like to get your feelings on where Conduit and/or OpenSync fit in to this. I understand that you guys are heading the charge on this, but especially wanted to draw your attention to Conduit. We are one of a handful of projects that have been already working with 'online desktop' goals in mind. It would be a shame if we couldn't work together when we have the same, or very similar, goals. So the purpose of my writing is to share our vision. I want to see how it compliments what you are trying to achieve and find out how we can best work together (and not end up duplicating our efforts!). Here is the state of Conduit for those of you not familiar with our work. For the Tomboy users... Conduit is currently able to sync your notes to an iPod, Evolution Memos or to Backpackit.com. Oh, and to any folder that GnomeVFS can see. Local, SSH or otherwise. I've not tried it myself, but it looks like you can also sync notes to Box.net... For those braver than average, running from SVN trunk gives you the ability (with some luck!) to sync your notes, contacts, and soon any type of data, to other Conduit instances over the network using a simple XML-RPC protocol with avahi discovery. (There is a low res video of laptop to laptop tomboy and evolution sync on my blog @ www.unrouted.co.uk) Ongoing work will see (or was originally designed to see) a Conduit Server emerge that you can run on a spare machine or, like me, you'll install it on your VPS/VM box. As your notes are synced from Tomboy on your laptop to the server they can be pushed out to other machines connected to the server. The server can use multiple plugins for storage - it could be flat files, it could be a database, it could be Google's BigTable. It's storing using the same plugins as normal Conduit - so the server could really be just passing everything back to Box.net!! The Conduit Server was then to lead on to a Django, TurboGears or otherwise Python based web app for viewing (and editing) your data online. Hosting it was a problem for us but we were hoping to get interest from the distros on that front. Also, as quite a small python app it would have been (hopefully) VPS friendly. This is pretty much defunct with online.gnome.org, though I don't think I could run my own personal gnome online on my VPS :)) We would like to see Conduit on other platforms - so you can sync the notes using your Mac, *** PC, or even your N800. (A native N800 port is likely to be the first of these). We are working with OpenSync devs to allow their plugins to work in Conduit, and eventually the use of their sync engine if desired. This will bring support for more devices (which is outside the scope of Online Desktop discussions, but worth mentioning). This includes the possibility of over-the-air phone sync... We aren't a sync GUI, we are a sync platform. Our dbus service provides sync for the whole desktop. An example, our API allows tomboy the option of syncing without involving the Conduit GUI at all. Tomboy can discover which targets are compatible with its Note datatype, create a group for that and sync. Similarly one click photo upload to Flickr,Picasa,Smugmug,iPod using eog is also in progress. As a project, I think we are good citizens. We have a history of working with other teams to enable sync. That includes bug reports and patches to Tomboy, patches to libgpod and even patches to SynCE. We maintain the python bindings for evolution, which we hope to eventually move upstream. If it's important to you to know how deployed we are, I know Conduit to be present in Foresight, Debian unstable, Ubuntu Universe (Gutsy) and Fedora Extras. Not really sure about the others... We are also working with one distro to enable Conduit out of the box in their next major release. So that's Conduit from a (mostly) notes perspective. In the online desktop climate, where do we fit in? * We can provide sync logic and conflict resolution. Intelligent client, server (or client for server) just needs a storage API. * We can provide Dataproviders for online.gnome.org services (and it should be a lot easier than Flickr and its frobs and tokens!). * Apps like Cheese can use our one-way sync api to push images to Flickr, and get online.gnome.org and other web services for free. I saw this in another e-mail: So it looks like we'll need to duplicate the work here, although putting additional pressure on Google to open source it is also a good idea. We have a guy working on bookmark sync for Epiphany, Simply Bookmark and Delicious to scratch his own itch :)... I don't know how far along he is though. An online.gnome.org backend would be quite easy too I imagine... So what are your thoughts? Also, could Conduit (at least the dbus part of it) merge in someway with the ideas of the Online Desktop Engine? Thanks for your time John Carr
