How to Access XMPP-Based Media Server

2010-11-12 Thread Jon Kristensen

Hello people!

My name is Jon Kristensen and I am planning to create a XMPP-based media 
server called Pontarius. The typical use case of Pontarius would be to 
host all your media on a local server and have that server share it with 
your friends (with customizable permissions, of course). The server will 
make sure that any transmission is end-to-end encrypted. We will be 
making heavy use of the XMPP protocol.


Now, I would like to make some kind of binding so that GNOME and other 
free desktop environments can browse the contents of a Pontarius server 
(so that you can see your and your friends media). Do you have any 
advice on where I should start? We will be using Jingle and the 
Publish-Subscribe XMPP extensions to do this. What is the lowest level 
layer that I can/should work against here?


Basically, I want to be able to work with the remote files as if they 
were a local directory... Get file listings, download a file, upload a 
file, rename a file, etc.


Thank you so much for any advice on this!

Warm regards,
Jon Kristensen
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: How to Access XMPP-Based Media Server

2010-11-12 Thread Cosimo Cecchi
On Fri, 2010-11-12 at 13:56 +0100, Jon Kristensen wrote:

 Now, I would like to make some kind of binding so that GNOME and other 
 free desktop environments can browse the contents of a Pontarius server 
 (so that you can see your and your friends media). Do you have any 
 advice on where I should start? We will be using Jingle and the 
 Publish-Subscribe XMPP extensions to do this. What is the lowest level 
 layer that I can/should work against here?

Hi, the Telepathy framework [1] is probably the best thing to interact
with  IM protocols in a desktop-neutral and interoperable way.

To make integration with the GNOME desktop seamless, the easier way is
then probably to write a GVfs backend based on Telepathy (or the XMPP
library you're going to use); that would allow the kind of integration
in the file manager and GTK+ applications you're trying to achieve.

[1] http://telepathy.freedesktop.org

Regards,

Cosimo

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


Re: Consolidating Core Desktop libraries

2010-11-12 Thread Bastien Nocera
On Tue, 2010-11-09 at 22:33 +0100, Giovanni Campagna wrote:
 Vincent asked me to send a mail to d-d-l aboutdb82a33 in
 gnome-desktop, that is: all libgnome-desktop include files have been
 moved to $(includedir)/gnome-desktop-3.0/libgnome-desktop.
 This is part of an other API break which is related to GnomeRR and
 introspection.
 
 I consider this an occasion for a bigger discussion on redesigning
 libgnome-desktop, moving forward from being the container of useful
 libgnome parts, to the One Desktop Library.

There are reasons why all those are separate, and I think we should
remember that.

 We're in the middle of moduleset reorganization, drawing a stricter line
 on what is core, and thus is expected to work only in GNOME and requires
 GNOME and is required by GNOME, such wm, the panels, the control center,
 the session daemons, and what is just an app using the GPlatform (GLib -
 GIO - Gtk), which therefore will work on every G- desktop environment.
 
 I believe this is the time for consolidating shared code used by this
 core modules into a libgnome-desktop, the same way we killed libgnome
 and merged useful features in Gtk / Gio.
 
 There is a lot of code which is copy-pasted around our desktop. For
 example, the GsdOsdWindow class, used by gnome-settings-daemon and
 gnome-power-manager, had to be updated several times because of Gtk
 breakages.

That's 2 users of the library, there's a similar one in Totem. But those
will be going away when we get those sort of notifications into the
shell directly.

 Another piece of copy-pasted code is gdmuser, which lives in
 gnome-panel, gdm and gnome-shell, and is constantly being updated
 because of accountsservice instability.

Then we need to make accountsservice more stable. And it could probably
ship a small library as well.

 Then there are microlibraries, killing which would help performance.
 These include for example libgtop, libgweather and libgnomekbd, but also

libgweather is small, but the data it drags in isn't.

 liboobs if the system tool backends are not dead.
 I can't find an use for them outside core desktop, while on the other
 hand there are already core desktop packages that depend on them.
 
 My proposal is then to take the classes included in these libraries or
 copy pasted sources, move them to the Gnome C namespace (GnomeDesktop
 GIR namespace) and add to libgnome-desktop.
 API stability is not an issue, as we all know that
 GNOME_DESKTOP_IS_UNSTABLE_API, and the only users of libgnome-desktop
 should live in the desktop modulesets, so that if we ever break API,
 we'll file patches before the affected maintainers even notices.
 
 I'm looking forward to read your comments on this.

I'm really not interested in seeing library aggregation of that sort.
We're striving to get rid of most of those, and they will disappear in
due time.

And if it were me, we'd kill gnome-desktop (as a library), and
copy/paste the very few bits between the modules that need it.

There's currently RandR helpers (g-s-d and control-center), wallpaper
handling code (g-s-d, control-center and nautilus), and the thumbnailer
(nautilus only, afaik).

The RandR stuff could be moved in g-s-d, and the wallpaper code as well,
when nautilus stops handling the desktop at some point in GNOME 3. And
nautilus could move the thumbnailer code to use itself.

Then gnome-desktop would only be a location for gnome-about.

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