Re: Dogfood servers now up
On Wed, 2007-08-01 at 10:59 -0400, Havoc Pennington wrote: Hi, Rodrigo Moya wrote: I can't create an account on neither of them. The first one's 'Send' button for obtaining a sign up link does nothing, and the second one just told me I'll be contacted once there's room for me :-( I forgot to include one of the javascript files, and then Owen started swapping out the XMPP server for a newer upstream version and so the latest svn was too busted to just push the quick fix. We'll get it fixed today. Bleeding edge svn snapshot, woot! OK, it's finally fixed now. Sorry for the delay. For those curious, the main benefit of upgrading to the latest version of Openfire (http://www.igniterealtime.org/projects/openfire/index.jsp) is that it makes it a lot easier to work on two of our most requested features: - Adding XMPP (Jabber) IM accounts [ http://bugzilla.mugshot.org/show_bug.cgi?id=1267 ] - Communication with the XMPP server via httpbind/BOSH (http://www.xmpp.org/extensions/xep-0206.html) to deal with firewalls [ http://bugzilla.mugshot.org/show_bug.cgi?id=1145 ] Though so far what I've done is just a straight upgrade. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
On 31/07/07, Havoc Pennington [EMAIL PROTECTED] wrote: This server is a test instance so we can eat our own dogfood, and any data on it may be nuked, accidentally leaked due to bugs in the code, etc. Generally we deploy to dogfood straight from SVN latest with no testing. Please adjust your expectations and behavior accordingly. Reporting bugs is good though, that's the point even. Is there a way to get an account on a test instance such as this one, for hacking on the Mugshot server? It's a nontrivial thing for me to get access to a Fedora box where I have permissions to install all the custom Java and things (or can persuade the admin to); I think I might have one in mind, but it'll be a while yet. It would be good if there was a way to test things without this barrier to entry. Of course, maybe I should just figure out how to install all the tools on Ubuntu (since there are at least two Ubuntu boxes I can test with at present) and document that-- but I thought I'd ask. peace Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
On Tue, 2007-07-31 at 16:38 -0700, Sanford Armstrong wrote: GNOME is going to have to become a service provider. as far as I see it, GNOME is already a (small though) service provider for online storing. That is, we have art.gnome.org for themes/icons, we have devel.gnome.org for devel docs, svn.gnome.org for code, etc So, the first thing that comes to my mind with this online desktop idea is to allow users to send their data to these GNOME servers. That is, a $gnome_art_designer would add support for uploading themes, users could write a technical white paper and upload it for other people to look at/help editing, etc. The online desktop for personal data storage makes a lot of sense (personal images, videos, calendars, adressbooks, etc), but it makes also a lot of sense for *shared* data storage. -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
On Tue, 2007-07-31 at 17:48 -0400, Havoc Pennington wrote: Hi, The bleeding edge server code is now up at: http://dogfood-online.gnome.org:9080/ And the old skin: http://dogfood.mugshot.org:9080/ I can't create an account on neither of them. The first one's 'Send' button for obtaining a sign up link does nothing, and the second one just told me I'll be contacted once there's room for me :-( -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
2007/8/1, Rodrigo Moya [EMAIL PROTECTED]: On Tue, 2007-07-31 at 16:38 -0700, Sanford Armstrong wrote: GNOME is going to have to become a service provider. as far as I see it, GNOME is already a (small though) service provider for online storing. That is, we have art.gnome.org for themes/icons, we have devel.gnome.org for devel docs, svn.gnome.org for code, etc So, the first thing that comes to my mind with this online desktop idea is to allow users to send their data to these GNOME servers. That is, a $gnome_art_designer would add support for uploading themes, users could write a technical white paper and upload it for other people to look at/help editing, etc. I was about to send a mail about it too. :-) Basically, a new art.gnome.org web site is going on (AGO3), as a SoC project. If I have some time, I would we've been working on an atom extension for themes on the current a.g.o. web, and I did a small app to consume those feeds[0]. I would love to add support to the control center for this feeds, however, I would like to consolidate the services to do so and think of a good ui for it. The second step is in progress already, but with the first one I'm quite lost, merging several theming sources (gnome-look, art.gnome.org) into one as a mashup and single point would be the ideal solution for this, so users don't need to handle those feeds within applications. [0] http://aruiz.typepad.com/siliconisland/2007/07/jilorio-gnome-b.html -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Hi, Sanford Armstrong wrote: How does this fit into the grand scheme of the online desktop? Tomboy can't be the only app that wants to store real data (not just configuration data) out there. I know Mugshot is meant mostly to bind existing services together, but how is a small free software project supposed to find the resources to offer a stable and performant web service to a large number of users? The answer for the Online Desktop can't always be store your data in an existing cool (proprietary) service. GNOME is going to have to become a service provider. I agree, the only way to make service-provider-dependent features usable is to have at least a default provider available, though people can also host their own. What is your order of magnitude on the size of someone's Tomboy notes? If they aren't very big then let's just try to get it going now. I can help on the server side if you can point me to some sense of what the data looks like, relevant source code, etc. Maybe we should also consider a web page to access your notes, which would let you get to them from a random internet kiosk and the like. For a small quota we can support quite a few users without too much trouble. Think a reasonable hard drive (200G) divided by a 10M quota. For a larger quota, one way we could approach it is that the server offers you a choice of storage providers. In implementation, this could mean that if I want to be a storage provider I either set up an S3 account or I provide the similar http-like S3 API on my own server - maybe just support sftp. Then users on online.gnome.org (or another instance of the same code) choose the storage provider they want to use. The server code already has the basic glue to speak WebDAV and forward it to S3, though it isn't enabled through any usable UI. This is only one possibility, though. We might have better ideas later. Something to consider, on the server we can store files or we can store database tables. They both have some advantages, with the database tables we can do fine-grained change notification over XMPP and it's easier to support a web view and web editing. With files it's easier to deal with large (exact definition fuzzy) data. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Hi, Thomas Thurman wrote: Is there a way to get an account on a test instance such as this one, for hacking on the Mugshot server? Not yet. The main practical problem right now is that the test instance is on the same machine as the real instance, which means if we gave you an account you could access real data not just test data. Of course, maybe I should just figure out how to install all the tools on Ubuntu (since there are at least two Ubuntu boxes I can test with at present) and document that-- but I thought I'd ask. Definitely this is needed and it should be pretty darn easy, I would say the only thing you have to do is repackage that JBoss RPM we have as a .deb. It doesn't have any system dependencies to speak of, it's all platform-independent Java code, so there should be essentially no work involved in doing this. Or even, you could just install the rpm with alien or rpm2cpio and I'm sure it would work fine. The jboss RPM is just a bunch of files afaik. Other than that the main requirements are simple and probably already available. The Sun JDK (for now - we expect the recently released 100% open source Java to work in the near future), and some common Java libs like ant and junit. If you start going through it, just bug someone on IRC as soon as you hit the slightest problem since we can probably tell you the answer much faster than if you spend time trying to figure it out. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Rodrigo Moya wrote: as far as I see it, GNOME is already a (small though) service provider for online storing. That is, we have art.gnome.org for themes/icons, we have devel.gnome.org for devel docs, svn.gnome.org for code, etc So, the first thing that comes to my mind with this online desktop idea is to allow users to send their data to these GNOME servers. That is, a $gnome_art_designer would add support for uploading themes, users could write a technical white paper and upload it for other people to look at/help editing, etc. That would be fantastic I think. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Hi, Alberto Ruiz wrote: Basically, a new art.gnome.org http://art.gnome.org web site is going on (AGO3), as a SoC project. If I have some time, I would we've been working on an atom extension for themes on the current a.g.o. web, and I did a small app to consume those feeds[0]. In addition to themes, I think it would be sweet if you could choose backgrounds from art.gnome.org and also photo sharing sites like Flickr in the control panel. And to make it more badass, have the control panel remember the original URL of the image, which combined with settings sync means if you log in to a fresh account your background would be downloaded ;-) Then of course there's the slideshow background from my photoset/tag feature... Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Hi, Rodrigo Moya wrote: I can't create an account on neither of them. The first one's 'Send' button for obtaining a sign up link does nothing, and the second one just told me I'll be contacted once there's room for me :-( I forgot to include one of the javascript files, and then Owen started swapping out the XMPP server for a newer upstream version and so the latest svn was too busted to just push the quick fix. We'll get it fixed today. Bleeding edge svn snapshot, woot! Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
2007/8/1, Havoc Pennington [EMAIL PROTECTED]: Hi, Alberto Ruiz wrote: Basically, a new art.gnome.org http://art.gnome.org web site is going on (AGO3), as a SoC project. If I have some time, I would we've been working on an atom extension for themes on the current a.g.o. web, and I did a small app to consume those feeds[0]. In addition to themes, I think it would be sweet if you could choose backgrounds from art.gnome.org and also photo sharing sites like Flickr in the control panel. Errr... have you seen the link at the bottom of my previous e-mail? Anyway, direct link to the screencast: http://youtube.com/watch?v=reB9TNRQ1Bg And to make it more badass, have the control panel remember the original URL of the image, which combined with settings sync means if you log in to a fresh account your background would be downloaded ;-) Then of course there's the slideshow background from my photoset/tag feature... That's the idea. :-) Havoc -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Online Desktop, Tomboy, and user storage (was Re: Dogfood servers now up)
On 8/1/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, Sanford Armstrong wrote: How does this fit into the grand scheme of the online desktop? Tomboy can't be the only app that wants to store real data (not just configuration data) out there. I know Mugshot is meant mostly to bind existing services together, but how is a small free software project supposed to find the resources to offer a stable and performant web service to a large number of users? The answer for the Online Desktop can't always be store your data in an existing cool (proprietary) service. GNOME is going to have to become a service provider. I agree, the only way to make service-provider-dependent features usable is to have at least a default provider available, though people can also host their own. What is your order of magnitude on the size of someone's Tomboy notes? If they aren't very big then let's just try to get it going now. I can help on the server side if you can point me to some sense of what the data looks like, relevant source code, etc. * * * Warning, boring details follow: * * * My test instance of Tomboy is 96 notes; the average Tomboy user probably has less than 500 notes. On the server where I am synchronizing those notes, I am using 432 KB. So I think 10 MB would be sufficient for most Tomboy users. Each note is stored in a separate .note file, which is just XML (typically 0.6-4.0 KB). For our file system sync backend, typical synchronization server layout looks like this (semi-inspired by svn repository layout, though don't be fooled...we are only storing the most recent revision for each note, there is no saved history): server-root/ manifest.xml - (maps notes to revision numbers) 0/ - (contains directories for revisions 0-99) 0/ - (contains notes from revision 0) x.note y.note 1/ - (contains notes from revision 1) z.note ... 1/ - (contains directories for revisions 100-199) 0/ - (contains notes from revision 100) ... A user can point to any path on their file system to use as a server (an nfs or smb mount, for example), or for WebDAV and SSH we automate the process using FUSE file systems wdfs and sshfs. The architecture for building sync service backends is pretty flexible, and third parties can develop their own using our addin architecture. Maybe we should also consider a web page to access your notes, which would let you get to them from a random internet kiosk and the like. This would be awesome and I have some sketches of what this might look like (plus we already have xsl transforms for exporting notes to HTML). But I don't think we have the resources to work on this before the end of the current cycle. For a small quota we can support quite a few users without too much trouble. Think a reasonable hard drive (200G) divided by a 10M quota. As mentioned above, that should be quite reasonable. Something to consider, on the server we can store files or we can store database tables. They both have some advantages, with the database tables we can do fine-grained change notification over XMPP and it's easier to support a web view and web editing. With files it's easier to deal with large (exact definition fuzzy) data. I need to read more about the data model design in Mugshot. But I can say that with regard to this cycle, the Tomboy team can't add support for any new sync backends that don't have a corresponding FUSE file system. If online.gnome.org can provide WebDAV access, we can very easily add support. Otherwise, we'll have to wait until September to start work on it. Of course, patches are always welcome. ;-) So to sum up, if Mugshot can provide free WebDAV shares for each user, then the basic needs are set for Tomboy synchronization. Awesome ideas for the future: * Web app for viewing notes, making notes public, viewing friends' notes, printing notes, and downloading arbitrary notes for inclusion on your local Tomboy instance * More generic API for note data transfer, so server can store data however it likes and user doesn't have to worry about installing wdfs, configuring FUSE, etc. These are all things I'm psyched to work on; just let me know what I can do to help! Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
Hi, Alberto Ruiz wrote: Errr... have you seen the link at the bottom of my previous e-mail? Anyway, direct link to the screencast: http://youtube.com/watch?v=reB9TNRQ1Bg Cool! Havoc ___ 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 (was Re: Dogfood servers now up)
On 8/2/07, Sanford Armstrong [EMAIL PROTECTED] wrote: On 8/1/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, Sanford Armstrong wrote: How does this fit into the grand scheme of the online desktop? Tomboy can't be the only app that wants to store real data (not just configuration data) out there. I know Mugshot is meant mostly to bind existing services together, but how is a small free software project supposed to find the resources to offer a stable and performant web service to a large number of users? The answer for the Online Desktop can't always be store your data in an existing cool (proprietary) service. GNOME is going to have to become a service provider. I agree, the only way to make service-provider-dependent features usable is to have at least a default provider available, though people can also host their own. What is your order of magnitude on the size of someone's Tomboy notes? If they aren't very big then let's just try to get it going now. I can help on the server side if you can point me to some sense of what the data looks like, relevant source code, etc. I agree with Sandys asessment on the need for this. When I looked into writing some kind of .Mac equivilent for Conduit to use as a central store to sync stuff with I inevitably came back to the same point, why write my own backend anything when things like WebDav and gnomevfs support for it already exist. According to http://live.gnome.org/OnlineDesktop we will basically store account info for people and the services they use. I dont think reinventing the wheel and writing a server side backend to store generic use data is all that effective use of time (putting aside concerns like bandwidth, storage space and security for the moment). Why not use apaches WebDav support and have it authenticate against online.gnome.org. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
On 7/31/07, Havoc Pennington [EMAIL PROTECTED] wrote: What we CAN do right now: if you want to store something on the web to be used by your app, you can test it against this dogfood server. If you need the ability to store something new, some of the Mugshot crew could generally add that ability in a matter of an hour or two, just ask. What are the limitations of storing something? I'm trying to figure out the logistics of setting up an official service for the new Tomboy note synchronization feature. Right now it's up to our users to find their own server space somewhere (preferably with WebDAV access). It would be really cool if our users could just enter their Mugshot/gnome.org/whatever credentials into Tomboy, and have their notes stored out there. Ideally they could then view their notes from their browser when they're on a strange machine. How does this fit into the grand scheme of the online desktop? Tomboy can't be the only app that wants to store real data (not just configuration data) out there. I know Mugshot is meant mostly to bind existing services together, but how is a small free software project supposed to find the resources to offer a stable and performant web service to a large number of users? The answer for the Online Desktop can't always be store your data in an existing cool (proprietary) service. GNOME is going to have to become a service provider. If there is already an answer for this, sorry for the noise. If this is part of a discussion that has yet to happen, I would love to be involved. :-) You guys are doing an awesome job getting the wheels turning on this initiative; it's very exciting! Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dogfood servers now up
quote who=Sanford Armstrong GNOME is going to have to become a service provider. That's one of the major undercurrents of discussion about the Online Desktop strategy. The Foundation is behind it, but we want to work closely with our Advisory Board partners to make sure that we don't end up at cross purposes, or competing in ugly ways. One of the ideas that has been raised is branded frontends, for instance. - Jeff -- linux.conf.au 2008: Melbourne, Australiahttp://lca2008.linux.org.au/ It's a pan-dimensional cake, and there are many ways to slice it. - Bruce Badger ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list