Re: GitHub Development Platform for GNOME

[Tobias Mueller]

Hi.

On So, 2017-04-09 at 15:44 -0400, Walter Vargas wrote:
> 
> Canonical's recent decision about not maintaining unity for Ubuntu makes it
> quite clear that Desktop is not the priority anymore, IoT and Mobile are the
> priority now,
Hah. Before it was the Cloud™, SOA, IVI, other form factors, ...  I
think it's fair to say that we've felt this threat for at least a
decade.

Now that doesn't necessarily make your point moot, but it may give a
perspective on why people seem to be relatively calm about the newest
coolest kid on the block.

> 
>  and now GitHub is the world leading development platform.
True.  But it wasn't the case five years ago and it might not be the
case anymore in five years.
I interpret your statement such that we should focus more on being on
Github, because it's where everybody else is and we surely want them to
make GNOME better.
I don't think we want to pay any price associated with getting the
maximum number of potential contributors.  The question then becomes
whether we are willing to pay the price associated with "switching to
Github".  For certain values of "switching to Github", the answer is
probably no; see below.

> 
> Since the primary goal is to provide a developer experience that does not act 
> as
> a barrier to new contributors,
I believe our primary goal is to produce excellent Free Software to
enable as many people as possible to do their computing.
But there will surely be someone who would argue otherwise and the more
people you ask the more answers you will get.

Providing a smooth contribution experience is certainly a means to
achieve that goal.  And I think we have to work on making it much more
smooth for people to produce code.

> 
> Should we be more pragmatic about that and reconsider GitHub as an option?
That's a fair question to ask.  I am wondering about that myself for a
while now.  I believe we are reluctant to accept having to rely on a
party sitting between us and the people wanting to make GNOME better.
 The reasons are manyfold.  My personal objection is that requiring
someone to agree to the ToS of a third party is a lot to ask for.  We
don't control the third party and it may very well decide to not
conduct business with certain people we would want to be able to
contribute. Just to invent a scenario: American companies may not be
allowed to deal with embargoed countries or people living there.  Now
that's not a concrete issue right now (AFAIK) but it may well become
one. (Also, the Github ToS, in particular, have stirred up some debate
recently)

On the other hand, it's probably fair to say that most people do have a
Github (Google, Facebook, ...) account already, so we're arriving here:

> 
> Is it a dogmatic foundational decision not to evaluate GitHub because it is 
> not
> Free Software?
To me, not being Free Software feels like the straw that breaks the
camel's back.

But it's not that we're not using Github.  We have invested some time
to have our self-hosted git mirrored to Github.  Some people also
accept patches via Github.
Are you thinking of using Github more?

Cheers,
  Tobi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitHub Development Platform for GNOME

[Philip Withnall]

On Mon, 2017-04-10 at 14:09 -0400, Nicolas Dufresne wrote:
> Le lundi 10 avril 2017 à 01:25 +0530, Nirbheek Chauhan a écrit :
> > On Mon, Apr 10, 2017 at 1:14 AM, Walter Vargas  > co
> > m> wrote:
> > > I want to share my humble opinion and thoughts about
> > > GitHub/GitLab:
> > > 
> > 
> > From what I've been hearing, people within GNOME have been
> > evaluating
> > the possibility of running our own GitLab instance, so I would wait
> > and see what the results of their testing is.
> 
> And we need not to forget that a lot of the freedesktop community [0]
> projects are moving to Phabricator (even though it does not come with
> an easy patch submission mechanism).

There’s git-phab, which is pretty good. You do need to install it
though (`pip3 install git-phab`).

If you don’t install git-phab, the patch upload process is basically
the same as Bugzilla: `git format-patch …` then attach it to a form and
submit.

Phabricator explicitly doesn’t support pull requests, and there’s some
justification for that in nudging people towards code review: https://s
ecure.phabricator.com/phame/post/view/766/write_review_merge_publish_ph
abricator_review_workflow/ (written by one of the Phabricator authors).

Phabricator’s patch review system is unsurpassed (in my experience of
GitHub, GitLab, Phabricator and Bugzilla) in its support for patch
sets, inter-diffs, and tracking review comments through multiple
iterations of a review. It’s beautiful. I think I’m in love.

Philip

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitHub Development Platform for GNOME

[Nicolas Dufresne]

Le lundi 10 avril 2017 à 01:25 +0530, Nirbheek Chauhan a écrit :
> On Mon, Apr 10, 2017 at 1:14 AM, Walter Vargas  m> wrote:
> > I want to share my humble opinion and thoughts about GitHub/GitLab:
> > 
> 
> From what I've been hearing, people within GNOME have been evaluating
> the possibility of running our own GitLab instance, so I would wait
> and see what the results of their testing is.

And we need not to forget that a lot of the freedesktop community [0]
projects are moving to Phabricator (even though it does not come with
an easy patch submission mechanism).

regards,
Nicolas

[0] https://phabricator.freedesktop.org

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitHub Development Platform for GNOME

[Carlos Soriano via desktop-devel-list]

Hello Walter,

Yes, using non-free software for something as important as our infraestructure 
is problematic for most of the GNOME community. GitHub is not a feasible option 
for the time being. Other alternatives that are free software can be and are 
being taken into account, and that's the path we should lead.

Best regards,
Carlos Soriano

 Original Message 
Subject: GitHub Development Platform for GNOME
Local Time: April 9, 2017 9:44 PM
UTC Time: April 9, 2017 7:44 PM
From: waltervar...@linux.com
To: desktop-devel-list@gnome.org

I want to share my humble opinion and thoughts about GitHub/GitLab:

I get worried about the long-term viability of the GNOME project after running
an iteration over OODA Loop (observe, orient, decide, act)[1].

Canonical's recent decision about not maintaining unity for Ubuntu makes it
quite clear that Desktop is not the priority anymore, IoT and Mobile are the
priority now, and now GitHub is the world leading development platform.

Since the primary goal is to provide a developer experience that does not act as
a barrier to new contributors, Should we be more pragmatic about that and
reconsider GitHub as an option?

Is it a dogmatic foundational decision not to evaluate GitHub because it is not
Free Software?

Kind Regards

[1] https://en.wikipedia.org/wiki/OODA_loop___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitHub Development Platform for GNOME

[Nirbheek Chauhan]

On Mon, Apr 10, 2017 at 1:14 AM, Walter Vargas  wrote:
> I want to share my humble opinion and thoughts about GitHub/GitLab:
>

>From what I've been hearing, people within GNOME have been evaluating
the possibility of running our own GitLab instance, so I would wait
and see what the results of their testing is.

Cheers,
Nirbheek
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GitHub Development Platform for GNOME

[Walter Vargas]

I want to share my humble opinion and thoughts about GitHub/GitLab:

I get worried about the long-term viability of the GNOME project after
running
an iteration over OODA Loop (observe, orient, decide, act)[1].

Canonical's recent decision about not maintaining unity for Ubuntu makes it
quite clear that Desktop is not the priority anymore, IoT and Mobile are the
priority now, and now GitHub is the world leading development platform.

Since the primary goal is to provide a developer experience that does not
act as
a barrier to new contributors, Should we be more pragmatic about that and
reconsider GitHub as an option?

Is it a dogmatic foundational decision not to evaluate GitHub because it is
not
Free Software?

Kind Regards

[1] https://en.wikipedia.org/wiki/OODA_loop
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome platform overview

[Alexander Larsson]

On tis, 2012-11-06 at 14:52 +0100, Pierre-Yves Luyten wrote:
 Hi, not sure writing to the right list, however:
 
 I was quickly looking at gnome platform overview on
 http://developer.gnome.org/
 or dedicated http://developer.gnome.org/platform-overview/stable/
 or http://developer.gnome.org/platform-overview/unstable/
 
 
 No gnome-online-account, zapojit, libgdata appear.
 I thought that I would find these in platform overview since they are 
 both part of the core gnome user experience and documented API.

The gnome platform is things we support for third party use. I'm not
sure the modules you list are in that category. At the very least
zapojit and libgdata are more like internal desktop implementation
libraries. Not sure about goa.

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

Re: Gnome platform overview

[Pierre-Yves Luyten]

On Fri, 09 Nov 2012 12:05:02 +0100, Alexander Larsson
al...@redhat.com wrote:
 On tis, 2012-11-06 at 14:52 +0100, Pierre-Yves Luyten wrote:
 Hi, not sure writing to the right list, however:

 I was quickly looking at gnome platform overview on
 http://developer.gnome.org/
 or dedicated http://developer.gnome.org/platform-overview/stable/
 or http://developer.gnome.org/platform-overview/unstable/


 No gnome-online-account, zapojit, libgdata appear.
 I thought that I would find these in platform overview since they are
 both part of the core gnome user experience and documented API.
 
 The gnome platform is things we support for third party use. I'm not
 sure the modules you list are in that category. At the very least
 zapojit and libgdata are more like internal desktop implementation
 libraries. Not sure about goa.

Sure, I thought about app on earth was to use the goa token and access
online accounts, but these answers make sense.

I did not know about the debate is it gnome core overview or gnome
for third parties overview. I guess a huge page pointing to everything
gnome core uses, including external libs or small widgets collections,
could be useful for brand new contributors, but seems another topic, and
wiki + blogs are already a very nice starting point.

Pierre-Yves

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

Re: Gnome platform overview

[Federico Mena Quintero]

On Tue, 2012-11-06 at 14:52 +0100, Pierre-Yves Luyten wrote:

 I was quickly looking at gnome platform overview on
 http://developer.gnome.org/
 or dedicated http://developer.gnome.org/platform-overview/stable/
 or http://developer.gnome.org/platform-overview/unstable/
 
 
 No gnome-online-account, zapojit, libgdata appear.
 I thought that I would find these in platform overview since they are 
 both part of the core gnome user experience and documented API.

You are completely correct.

The Platform Overview is getting a bit stale, and it would definitely be
good to update it with newer modules or pieces of public infrastructure.
If you feel familiar enough with the modules you mentioned, would you be
able to write a patch for the platform overview document?  The source is
at git://git.gnome.org/git/gnome-devel-docs (although I'm not sure about
the platform-overview vs. new-platform-overview in that module - the
latter seems a Mallard translation of the former).

  Federico

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

Re: Gnome platform overview

[Shaun McCance]

On Wed, 2012-11-07 at 09:36 -0600, Federico Mena Quintero wrote:
 On Tue, 2012-11-06 at 14:52 +0100, Pierre-Yves Luyten wrote:
 
  I was quickly looking at gnome platform overview on
  http://developer.gnome.org/
  or dedicated http://developer.gnome.org/platform-overview/stable/
  or http://developer.gnome.org/platform-overview/unstable/
  
  
  No gnome-online-account, zapojit, libgdata appear.
  I thought that I would find these in platform overview since they are 
  both part of the core gnome user experience and documented API.
 
 You are completely correct.
 
 The Platform Overview is getting a bit stale, and it would definitely be
 good to update it with newer modules or pieces of public infrastructure.
 If you feel familiar enough with the modules you mentioned, would you be
 able to write a patch for the platform overview document?  The source is
 at git://git.gnome.org/git/gnome-devel-docs (although I'm not sure about
 the platform-overview vs. new-platform-overview in that module - the
 latter seems a Mallard translation of the former).

They're both in Mallard. The new Platform Overview was started by Phil
to give us something a bit stronger than a module listing, which is
what the Platform Overview has fallen into since about 3.0.

To the original question: we have always had the problem of deciding
what goes into the PO. Is it the core, stable libraries? Everything
we use anywhere? Do we include non-GObject stuff that we nonetheless
heavily use? I'd never heard of zapojit before now. Is this something
we expect a lot of developers to use?

(First hit when I search online is the reference manual on developer.
That's good. The first screenful on that page doesn't tell me what to
use zapojit for. It tells me about its license. That's not good.)

--
Shaun


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

Re: Gnome platform overview

[Debarshi Ray]

 No gnome-online-account, zapojit, libgdata appear.
 I thought that I would find these in platform overview since they are 
 both part of the core gnome user experience and documented API.

 [...]
 
 To the original question: we have always had the problem of deciding
 what goes into the PO. Is it the core, stable libraries? Everything
 we use anywhere? Do we include non-GObject stuff that we nonetheless
 heavily use?

Exactly. Moreover, it is not clear to me if we want 3rd parties to use GOA
or not. While it would give better integration with the platform (ie. GNOME)
if they do, there are concerns about diluting the GNOME brand.

 I'd never heard of zapojit before now. Is this something
 we expect a lot of developers to use?

The answer to that is the same as the answer for libgdata, with the exception
that libzapojit is not meant to be API/ABI stable yet. After all it is 2 weeks
old. :-)

 (First hit when I search online is the reference manual on developer.
 That's good. The first screenful on that page doesn't tell me what to
 use zapojit for. It tells me about its license. That's not good.)

Scroll down a bit and it becomes pretty clear, but yes, you are right. It
can be improved.

Happy hacking,
Debarshi

-- 
There are two hard problems in computer science: cache invalidation, naming
things and off-by-one errors.


pgpgy9ZHn7o61.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Gnome platform overview

[Pierre-Yves Luyten]

Hi, not sure writing to the right list, however:

I was quickly looking at gnome platform overview on
http://developer.gnome.org/
or dedicated http://developer.gnome.org/platform-overview/stable/
or http://developer.gnome.org/platform-overview/unstable/


No gnome-online-account, zapojit, libgdata appear.
I thought that I would find these in platform overview since they are 
both part of the core gnome user experience and documented API.


Maybe just a TODO someone already knows, or maybe is my idea wrong?

Regards
Pierre

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

Re: I need your help with the Platform Overview

[Federico Mena Quintero]

On Wed, 2011-04-06 at 10:11 -0400, Shaun McCance wrote:

 I was up late last night trying to get all the pieces together
 for the Platform Overview.

Sweet; thanks for updating this.

I'm just starting to read projectmallard.org.  Do you have something
that one can drop into Emacs's psgml-mode so that it will automatically
suggest element names and such?

  Federico

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

Re: I need your help with the Platform Overview

[Shaun McCance]

On Tue, 2011-04-12 at 11:23 -0500, Federico Mena Quintero wrote:
 On Wed, 2011-04-06 at 10:11 -0400, Shaun McCance wrote:
 
  I was up late last night trying to get all the pieces together
  for the Platform Overview.
 
 Sweet; thanks for updating this.
 
 I'm just starting to read projectmallard.org.  Do you have something
 that one can drop into Emacs's psgml-mode so that it will automatically
 suggest element names and such?

I don't use psgml-mode, so I don't know what kinds of formats
it can take. I use nxml-mode, which works with RNG compact
syntax files. For that, there's this:

http://projectmallard.org/1.0/mallard-1.0.rnc

--
Shaun


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

Re: I need your help with the Platform Overview

[Federico Mena Quintero]

On Tue, 2011-04-12 at 12:31 -0400, Shaun McCance wrote:

 I don't use psgml-mode, so I don't know what kinds of formats
 it can take. I use nxml-mode, which works with RNG compact
 syntax files. For that, there's this:
 
 http://projectmallard.org/1.0/mallard-1.0.rnc

Excellent, thanks.  I'll try it out.

(psgml-mode takes DTDs; no idea if it takes RNG as well)

  Federico

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

I need your help with the Platform Overview

[Shaun McCance]

I was up late last night trying to get all the pieces together
for the Platform Overview. I wish I could have gotten to this
sooner, but the new user help has consumed me for the last few
weeks. It's become clear to me that I can't write and maintain
this on my own.

Fortunately, the new structure is topic-oriented, and it's much
simpler. So everybody can just take a page and work on it. What
I'd like is for library developers to take ownership of their
library in the Platform Overview. That means the Telepathy page
is written by the Telepathy developers, the Clutter page is
written by the Clutter developers, and so on.

The Overview is as much about marketing as it is documentation.
So this is you promoting your hard work. I can still help with
style and markup, of course. I'm not just washing my hands of
this. But I need your help to make this not crap.

View the Overview in git here:

git clone ssh://git.gnome.org/git/gnome-devel-docs
cd gnome-devel-docs/platform-overview/C
yelp .

Some of the pages are copied from the old Overview, and are
more or less OKish (though the writing style is more formal
than what we do these days). Some only have a sentence or
two, because I gave up last night. Some were removed, not
because I don't like them, but because I didn't get to them.
They're sitting in git as .page.stub files. (To see them in
Yelp, pass --editor-mode)

There's a common format pages should follow. It's simple.

* One paragraph on what the technology is
* One or more paragraphs hyping its features and design
* Final paragraph saying when to use the library
* List of links:
  - A tutorial, if available (our new demos are best)
  - Reference documentation
  - Web site, if useful

If you care about your library being part of the GNOME
developer platform, please take an hour out of your day
to write about it. I will make very regular releases of
documentation packages for 3.0, so we can get new content
onto developer.gnome.org quickly.

Thanks,
Shaun


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

Re: I need your help with the Platform Overview

[Emmanuele Bassi]

hi;

On 6 April 2011 15:11, Shaun McCance sha...@gnome.org wrote:
 If you care about your library being part of the GNOME
 developer platform, please take an hour out of your day
 to write about it. I will make very regular releases of
 documentation packages for 3.0, so we can get new content
 onto developer.gnome.org quickly.

the only question I have is: how do we submit the content for review?
bugzilla? mailing list?

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: I need your help with the Platform Overview

[Johannes Schmid]

Hi!

 the only question I have is: how do we submit the content for review?
 bugzilla? mailing list?

Just commit it to gnome-devel-docs directly I would say. Though
gnome-docs-list will also work but I am pretty confident that you (and
other library maintainers) know what they write and it can be reviewed
later anyway.

Regards,
Johannes



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: I need your help with the Platform Overview

[Shaun McCance]

On Wed, 2011-04-06 at 17:42 +0100, Emmanuele Bassi wrote:
 hi;
 
 On 6 April 2011 15:11, Shaun McCance sha...@gnome.org wrote:
  If you care about your library being part of the GNOME
  developer platform, please take an hour out of your day
  to write about it. I will make very regular releases of
  documentation packages for 3.0, so we can get new content
  onto developer.gnome.org quickly.
 
 the only question I have is: how do we submit the content for review?
 bugzilla? mailing list?

I'm flexible. If you think what you've got is good (and it's
almost certainly better than what's there), just commit it.
I'll look over everything before making point releases.
Or put it in bugzilla, product gnome-devel-docs.

If you want some discussion or feedback, gnome-doc-list is
good. Or catch me on IRC.

Thanks,
Shaun



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

Adding telepathy-glib to Extended Platform [Was: Modulesets Reorganization]

[Guillaume Desmottes]

Le mercredi 02 juin 2010 à 00:37 +0100, Lucas Rocha a écrit :
 3. Create a moduleset to hold our highly recommended libraries such GStreamer,
 e-d-s, and others. This moduleset will be called Extended Platform.

This is very good news!

What's the procedure to propose module to this new moduleset?

We'd like to propose telepathy-glib which, I think, could be a good
candidate:

- Currently used by Empathy, Vino and Vinagre.

- We are currently working on adding gobject-introspection to high level
clients API. Projects such as Zeitgeist and gnome-shell plan to use it.

- tp-glib is API and ABI stable: 0.odd.x has the same API guarantees as
0.even.x.

- All the API is documented:
http://telepathy.freedesktop.org/doc/telepathy-glib/

- 0.odd.x are development releases and we make stable release in time
for GNOME stable releases. For example, Empathy 2.31.x depends on
telepathy-glib 0.11.x and Empathy 2.32.0 will depends on telepathy-glib
0.12.0


Let us know what you think.
Thanks!


G.


-- 
Guillaume Desmottes gdesm...@gnome.org
Jabber cass...@jabber.belnet.be
GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169  E28A AC55 8671 711E 31B1

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

Re: [gnome-db] Platform for Developer Documentation

[Piotr Pokora]

Daniel Espinosa pisze:

Hi!

 I think GDA must be considered, as a developer platform, because
 Anjuta depends on it. I think other projects may can take advantage of
 its features to save metadata, documents, history, etc. on database
 engines and share with others by using central servers or so.

We develope Midgard content repository.
It's build on top of Gnome stack (and Libgda of course) and can be
used as centralized or distributed repository.

http://bergie.iki.fi/blog/getting_started_with_the_midgard_content_repository/
http://www.midgard-project.org/api-docs/midgard/core/9.9/

Among mentioned features it also provides very nice replication
possibilities and language bindings: C, Python, PHP, Objective-C and Vala.

Piotras

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

Re: Platform for Developer Documentation

[Daniel Espinosa]

I think GDA must be considered, as a developer platform, because
Anjuta depends on it. I think other projects may can take advantage of
its features to save metadata, documents, history, etc. on database
engines and share with others by using central servers or so.

2010/3/8 Alberto Ruiz ar...@gnome.org:
 2010/3/8 Josselin Mouette j...@debian.org:
 Le dimanche 07 mars 2010 à 15:16 -0600, Shaun McCance a écrit :
 * PackageKit

 I don’t think we should consider PackageKit as a core development
 interface, but rather as an optional service. It doesn’t integrate
 properly with all distributions, and not all user setups make it useful,
 especially the largest installations.

 Release often, release early. The only way to improve support is to
 embrace it and push its adoption and get people to file bugs.

 * PulseAudio

 Maybe it’s (still) a little too early to consider it? Support for a wide
 range of hardware is still very poor as of kernel 2.6.32.

 Same here.

 I'm growing a bit sick of GNOME having to be in this limbo situation
 where it can't stick to any technology because downstream
 distributions choose not to ship some components by default.

 PackageKit and PulseAudio are two projects that are pretty well
 aligned with the GNOME platform in terms of API technology and goals,
 they solve hard problems to solve, they don't have any real contenders
 (yes they have problems, but if we wait until they are perfect, we
 will never have a platform).

 So my take on this is, embrace those, help downstream to embrace them,
 but let's not hold back or we will end up with a half arsed platform
 that tries to solve everyone's problems and will end up solving no
 one's.

 Furthermore, if you want to consider hardware support, maybe you can
 talk about GUdev? It’s still Linux-specific, but currently it is the way
 to go.

 --
  .''`.      Josselin Mouette
 : :' :
 `. `'   “I recommend you to learn English in hope that you in
  `-     future understand things”  -- Jörg Schilling

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




 --
 Un saludo,
 Alberto Ruiz
 ___
 gnome-doc-list mailing list
 gnome-doc-l...@gnome.org
 http://mail.gnome.org/mailman/listinfo/gnome-doc-list




-- 
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (en trámite, pero para los
cuates: LIBRE)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Tomeu Vizoso]

On Sun, Mar 7, 2010 at 22:16, Shaun McCance sha...@gnome.org wrote:
 Hi folks,

 I'm working on what to include in the Platform Overview.
 This affects what gets focused on in the introductions
 and howtos in my developer documentation plan:

 http://live.gnome.org/DocumentationProject/Planning/DeveloperDocs

 I've tried starting this discussion before, but haven't
 gotten a lot of response.  So rather than ask, I'm going
 to propose a list of technologies and see if there are
 any objections.

Have you considered talking a bit about coarser components such as
abiwidget, evince, vte, webkit/gtk+, tinymail-ui, gtksourceview,
empathy-gtk, etc?

Regards,

Tomeu

 I'm taking the big tent approach.  If we're using it,
 and it's not something we consider to be a system library,
 then it's in.  I don't care if it's in the platform, the
 desktop, or the external dependencies.  I want to present
 third-party developers with the most complete development
 platform possible.

 I also want to focus on developer tools.  They should be
 featured heavily when we talk about how to develop for
 Gnome.

 Enough yakking.  Libraries I'm going to push:

 * GTK+
 * GLib (+ GObject, GIO, GSettings)
 * Pango
 * Cairo
 * ATK
 * AT-SPI
 * Clutter
 * PackageKit
 * Tracker
 * Telepathy
 * Evolution Data Server
 * Gnome Keyring
 * GStreamer
 * WebKitGTK+
 * Soup
 * Avahi
 * DBus
 * DeviceKit-disks
 * DeviceKit-power
 * Canberra
 * PolicyKit
 * PulseAudio

 I'm going to focus on the following programming languages:

 * C
 * C++
 * Java
 * JavaScript
 * C#
 * Perl
 * Python

 Developer tools I'll be pushing:

 * Anjuta
 * Devhelp
 * Glade
 * Accerciser
 * Nemiver

 On top of this, I would like to have a section where we
 highlight application plugin APIs.  I'll be hunting for
 places where developers can plug into our desktop.  If
 you want your application highlighted, send me an email
 to make sure I don't overlook it.

 I'm going to begin sketching out the content plan for
 the Platform Overview based on this.  If I've forgotten
 something, please tell me.  If you feel strongly that
 anything I mentioned should not be pushed, speak up.

 After the Overview content is planned, I'll begin work
 on planning the introductions.  These are the going to
 be the first thing a lot of new developers see, so we
 have to make them rock.

 Happy hacking.

 --
 Shaun McCance
 http://syllogist.net/

 ___
 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: Platform for Developer Documentation

[Alberto Ruiz]

2010/3/8 Tomeu Vizoso to...@tomeuvizoso.net:
 Have you considered talking a bit about coarser components such as
 abiwidget, evince, vte, webkit/gtk+, tinymail-ui, gtksourceview,
 empathy-gtk, etc?

Guys, I think Shaun is trying to focus in a handful of components
first, the main ones, he already has a lot on his plate, so rather
than suggest him more work I think we should all try to find a way to
support him and contribute to this huge task.

I for one, will try to align my GNOME TV next videos with the content
set Shaun is proposing. What are you gonna do guys?

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

Re: Platform for Developer Documentation

[Josselin Mouette]

Le dimanche 07 mars 2010 à 15:16 -0600, Shaun McCance a écrit : 
 * PackageKit

I don’t think we should consider PackageKit as a core development
interface, but rather as an optional service. It doesn’t integrate
properly with all distributions, and not all user setups make it useful,
especially the largest installations.

 * PulseAudio

Maybe it’s (still) a little too early to consider it? Support for a wide
range of hardware is still very poor as of kernel 2.6.32.


Furthermore, if you want to consider hardware support, maybe you can
talk about GUdev? It’s still Linux-specific, but currently it is the way
to go.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Alberto Ruiz]

2010/3/8 Josselin Mouette j...@debian.org:
 Le dimanche 07 mars 2010 à 15:16 -0600, Shaun McCance a écrit :
 * PackageKit

 I don’t think we should consider PackageKit as a core development
 interface, but rather as an optional service. It doesn’t integrate
 properly with all distributions, and not all user setups make it useful,
 especially the largest installations.

Release often, release early. The only way to improve support is to
embrace it and push its adoption and get people to file bugs.

 * PulseAudio

 Maybe it’s (still) a little too early to consider it? Support for a wide
 range of hardware is still very poor as of kernel 2.6.32.

Same here.

I'm growing a bit sick of GNOME having to be in this limbo situation
where it can't stick to any technology because downstream
distributions choose not to ship some components by default.

PackageKit and PulseAudio are two projects that are pretty well
aligned with the GNOME platform in terms of API technology and goals,
they solve hard problems to solve, they don't have any real contenders
(yes they have problems, but if we wait until they are perfect, we
will never have a platform).

So my take on this is, embrace those, help downstream to embrace them,
but let's not hold back or we will end up with a half arsed platform
that tries to solve everyone's problems and will end up solving no
one's.

 Furthermore, if you want to consider hardware support, maybe you can
 talk about GUdev? It’s still Linux-specific, but currently it is the way
 to go.

 --
  .''`.      Josselin Mouette
 : :' :
 `. `'   “I recommend you to learn English in hope that you in
  `-     future understand things”  -- Jörg Schilling

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




-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Josselin Mouette]

Le lundi 08 mars 2010 à 15:54 +, Alberto Ruiz a écrit : 
 I'm growing a bit sick of GNOME having to be in this limbo situation
 where it can't stick to any technology because downstream
 distributions choose not to ship some components by default.

Ever wondered why we choose not to ship those components?

 PackageKit and PulseAudio are two projects that are pretty well
 aligned with the GNOME platform in terms of API technology and goals,
 they solve hard problems to solve, they don't have any real contenders
 (yes they have problems, but if we wait until they are perfect, we
 will never have a platform).

So far, I think these projects are clearly not on par with the rest of
GNOME in terms of stability and integration.

 So my take on this is, embrace those, help downstream to embrace them,
 but let's not hold back or we will end up with a half arsed platform
 that tries to solve everyone's problems and will end up solving no
 one's.

I’m still missing the “help downstream to embrace them” part. In
previous GNOME releases, the only way to get some of the GNOME
components to work correctly was to patch out the pieces based on
unusable technologies.

So far, new technologies have always stabilized pretty well after a
couple more releases (e.g. GIO and devicekit-* for recent successful
examples) but specifically for PulseAudio and PackageKit, I have not
witnessed significant progress. PackageKit is being made to work thanks
to a reimplementation of the D-Bus API (SessionInstaller), and
PulseAudio is still pointing fingers at the kernel, without enough
apparent progress being made in the kernel.

To sum up, I’m certainly not advocating any kind of technology
stagnation and I encourage all developers to keep on improving and
redesigning software layers, but I also encourage you to have a look
behind and wonder whether new technologies were actually successful.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Brian Cameron]

Alberto/Shaun:

I agree that there is no reason why the developer docs should not
include good documentation for modules such as PackageKit, PulseAudio,
PolicyKit, and udev (DeviceKit  friends or whatever they are called
this month).

That said, OpenSolaris does not distribute any of these.  How distros
manage packages can be very distro specific, so PackageKit is likely
not a good fit for everyone.  On OpenSolaris, PolicyKit has never been
adopted due to the fact that OpenSolaris uses RBAC which provides (or
can provide) similar functionality.  udev is currently very Linux
specific.  I am a bit on the fence about PulseAudio - perhaps it may be
integrated into OpenSolaris at some point, though it seems far more
useful  interesting when using Linux-specific ALSA.

I do recognize that most people who distribute GNOME ship with these
modules, so I am all for delivering good documentation for them.

However, I do think more energy should be focused on the truly
cross-platform interfaces that everybody uses.  At the very least, the
documentation should avoid making assumptions about these sorts of
interfaces being used by everyone.  Especially when information about
these interfaces are mentioned in the documentation for truly cross-
platform interfaces.  For example, if the docs for a desktop
application like totem or nautilus needs to discuss udev of PolicyKit,
it should be made clear that not everybody uses these and that other
mechanisms may need to be used on some distros.

Brian


On 03/ 8/10 09:54 AM, Alberto Ruiz wrote:

2010/3/8 Josselin Mouettej...@debian.org:

Le dimanche 07 mars 2010 à 15:16 -0600, Shaun McCance a écrit :

* PackageKit


I don’t think we should consider PackageKit as a core development
interface, but rather as an optional service. It doesn’t integrate
properly with all distributions, and not all user setups make it useful,
especially the largest installations.


Release often, release early. The only way to improve support is to
embrace it and push its adoption and get people to file bugs.


* PulseAudio


Maybe it’s (still) a little too early to consider it? Support for a wide
range of hardware is still very poor as of kernel 2.6.32.


PackageKit and PulseAudio are two projects that are pretty well
aligned with the GNOME platform in terms of API technology and goals,
they solve hard problems to solve, they don't have any real contenders
(yes they have problems, but if we wait until they are perfect, we
will never have a platform).

So my take on this is, embrace those, help downstream to embrace them,
but let's not hold back or we will end up with a half arsed platform
that tries to solve everyone's problems and will end up solving no
one's.


Furthermore, if you want to consider hardware support, maybe you can
talk about GUdev? It’s still Linux-specific, but currently it is the way
to go.

--
  .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling

___
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: Platform for Developer Documentation

[John Stowers]

 
 I'm growing a bit sick of GNOME having to be in this limbo situation
 where it can't stick to any technology because downstream
 distributions choose not to ship some components by default.
 
 PackageKit and PulseAudio are two projects that are pretty well
 aligned with the GNOME platform in terms of API technology and goals,
 they solve hard problems to solve, they don't have any real contenders
 (yes they have problems, but if we wait until they are perfect, we
 will never have a platform).

Forgive me if I misrepresent Lennart here, but I thought the PulseAudio
policy [1] was use GStreamer, libcanberra or ALSA (if you know what you
are doing), and then PulseAudio will keep out of your way. 

Therefore, for the purposes of this list, having GStreamer and Canberra
present is sufficient.

John

[1] http://0pointer.de/blog/projects/guide-to-sound-apis.html


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

Re: Platform for Developer Documentation

[Shaun McCance]

On Mon, 2010-03-08 at 10:23 -0600, Brian Cameron wrote:
 However, I do think more energy should be focused on the truly
 cross-platform interfaces that everybody uses.  At the very least, the
 documentation should avoid making assumptions about these sorts of
 interfaces being used by everyone.  Especially when information about
 these interfaces are mentioned in the documentation for truly cross-
 platform interfaces.  For example, if the docs for a desktop
 application like totem or nautilus needs to discuss udev of PolicyKit,
 it should be made clear that not everybody uses these and that other
 mechanisms may need to be used on some distros.

OK, I was anticipating this being a hot topic.  Conversations
have been civil so far (thanks everybody), but let me try to
preempt nastiness with a proposal.

In the Platform Overview, for each technology, we can make a
note of which platforms it's available/encouraged on.  We can
even link those into pages which list the approved technologies
for that platform.  This would also give us a way to highlight
how our platform can be used to create applications for other
operating systems, or even on special Gnome-based platforms.

This, of course, opens a new can of worms.  I am not going to
list every distro under the sun.  Lumping GNU/Linux together
won't work, because there's differences with PackageKit.

--
Shaun


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

Re: Platform for Developer Documentation

[Alberto Ruiz]

2010/3/8 John Stowers john.stowers.li...@gmail.com:
 Forgive me if I misrepresent Lennart here, but I thought the PulseAudio
 policy [1] was use GStreamer, libcanberra or ALSA (if you know what you
 are doing), and then PulseAudio will keep out of your way.

 Therefore, for the purposes of this list, having GStreamer and Canberra
 present is sufficient.

Thanks a lot for the comments John, that is probably the best way to go.
(now that I think about it, I don't think my comment was very useful
for the thread, I apologize for starting a flame here)

-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Danielle Madeley]

On Mon, 2010-03-08 at 09:57 +0100, Tomeu Vizoso wrote:

 Have you considered talking a bit about coarser components such as
 abiwidget, evince, vte, webkit/gtk+, tinymail-ui, gtksourceview,
 empathy-gtk, etc?

There is no libempathy-* any longer.

All programming should be done with telepathy-glib directly. Though in
the future there will also be a telepathy-gtk.

-- 
Danielle Madeley
Software Developer, Collabora Ltd.  Melbourne, Australia

www.collabora.co.uk

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

Platform for Developer Documentation

[Shaun McCance]

Hi folks,

I'm working on what to include in the Platform Overview.
This affects what gets focused on in the introductions
and howtos in my developer documentation plan:

http://live.gnome.org/DocumentationProject/Planning/DeveloperDocs

I've tried starting this discussion before, but haven't
gotten a lot of response.  So rather than ask, I'm going
to propose a list of technologies and see if there are
any objections.

I'm taking the big tent approach.  If we're using it,
and it's not something we consider to be a system library,
then it's in.  I don't care if it's in the platform, the
desktop, or the external dependencies.  I want to present
third-party developers with the most complete development
platform possible.

I also want to focus on developer tools.  They should be
featured heavily when we talk about how to develop for
Gnome.

Enough yakking.  Libraries I'm going to push:

* GTK+
* GLib (+ GObject, GIO, GSettings)
* Pango
* Cairo
* ATK
* AT-SPI
* Clutter
* PackageKit
* Tracker
* Telepathy
* Evolution Data Server
* Gnome Keyring
* GStreamer
* WebKitGTK+
* Soup
* Avahi
* DBus
* DeviceKit-disks
* DeviceKit-power
* Canberra
* PolicyKit
* PulseAudio

I'm going to focus on the following programming languages:

* C
* C++
* Java
* JavaScript
* C#
* Perl
* Python

Developer tools I'll be pushing:

* Anjuta
* Devhelp
* Glade
* Accerciser
* Nemiver

On top of this, I would like to have a section where we
highlight application plugin APIs.  I'll be hunting for
places where developers can plug into our desktop.  If
you want your application highlighted, send me an email
to make sure I don't overlook it.

I'm going to begin sketching out the content plan for
the Platform Overview based on this.  If I've forgotten
something, please tell me.  If you feel strongly that
anything I mentioned should not be pushed, speak up.

After the Overview content is planned, I'll begin work
on planning the introductions.  These are the going to
be the first thing a lot of new developers see, so we
have to make them rock.

Happy hacking.

-- 
Shaun McCance
http://syllogist.net/

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

Re: Platform for Developer Documentation

[Philip Withnall]

On Sun, 2010-03-07 at 15:16 -0600, Shaun McCance wrote:
 Hi folks,

*snip*

 On top of this, I would like to have a section where we
 highlight application plugin APIs.  I'll be hunting for
 places where developers can plug into our desktop.  If
 you want your application highlighted, send me an email
 to make sure I don't overlook it.

Totem and Rhythmbox are notable examples.

 I'm going to begin sketching out the content plan for
 the Platform Overview based on this.  If I've forgotten
 something, please tell me.  If you feel strongly that
 anything I mentioned should not be pushed, speak up.

What about libnotify, libunique and libxml2? They're fairly commonly
used, but I'm not sure if we should be pushing them. There's still talk
of including the functionality of the first two in GTK+/GLib, while
libxml2 is hardly a shining example of a usable or well-documented
library.

What about jhbuild, Alleyoop and D-Feet for applications? jhbuild is
vital for anyone wanting to build GNOME, Alleyoop is in the same vein as
Nemiver, and D-Feet should be pushed if you're pushing D-Bus.

I've got no problems with the rest of the list. :-)

Regards,
Philip

 After the Overview content is planned, I'll begin work
 on planning the introductions.  These are the going to
 be the first thing a lot of new developers see, so we
 have to make them rock.
 
 Happy hacking.
 



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Emilio Pozuelo Monfort]

On 07/03/10 22:16, Shaun McCance wrote:
 I'm going to focus on the following programming languages:
 
 * C
 * C++
 * Java
 * JavaScript
 * C#
 * Perl
 * Python

 I'm going to begin sketching out the content plan for
 the Platform Overview based on this.  If I've forgotten
 something, please tell me.  If you feel strongly that
 anything I mentioned should not be pushed, speak up.

Looks like you forgot Vala.

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

Re: Platform for Developer Documentation

[Alberto Ruiz]

2010/3/7 Emilio Pozuelo Monfort po...@ubuntu.com:
 On 07/03/10 22:16, Shaun McCance wrote:
 I'm going to focus on the following programming languages:

 * C
 * C++
 * Java
 * JavaScript
 * C#
 * Perl
 * Python

 I'm going to begin sketching out the content plan for
 the Platform Overview based on this.  If I've forgotten
 something, please tell me.  If you feel strongly that
 anything I mentioned should not be pushed, speak up.

 Looks like you forgot Vala.

Yeah, I know some people has the feeling that Vala is a toy language,
however, is the language with the best gobject introspection support
and I think it has a lot to add to the GNOME learning/community
building story, given that it is easy to approach and at the same time
it produces libraries that everyone can reuse (btw, Vala native
libraries can output perfect GIR files so you get introspection out of
the box with it).

I think we should give less priority to C when it comes to
documentation in the site, C is fine for the guys working whithin the
platform, but is not the best choice for application developers. Vala,
Python, Mono and C# are probably the best targets in this regard and
we should promote them to have even more relevance than C where
possible (with ease of access to the people looking for the C docs
anyway).

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




-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Robert Ancell]

Is soup required now that we have GIO?

On 8 March 2010 08:16, Shaun McCance sha...@gnome.org wrote:
 Hi folks,

 I'm working on what to include in the Platform Overview.
 This affects what gets focused on in the introductions
 and howtos in my developer documentation plan:

 http://live.gnome.org/DocumentationProject/Planning/DeveloperDocs

 I've tried starting this discussion before, but haven't
 gotten a lot of response.  So rather than ask, I'm going
 to propose a list of technologies and see if there are
 any objections.

 I'm taking the big tent approach.  If we're using it,
 and it's not something we consider to be a system library,
 then it's in.  I don't care if it's in the platform, the
 desktop, or the external dependencies.  I want to present
 third-party developers with the most complete development
 platform possible.

 I also want to focus on developer tools.  They should be
 featured heavily when we talk about how to develop for
 Gnome.

 Enough yakking.  Libraries I'm going to push:

 * GTK+
 * GLib (+ GObject, GIO, GSettings)
 * Pango
 * Cairo
 * ATK
 * AT-SPI
 * Clutter
 * PackageKit
 * Tracker
 * Telepathy
 * Evolution Data Server
 * Gnome Keyring
 * GStreamer
 * WebKitGTK+
 * Soup
 * Avahi
 * DBus
 * DeviceKit-disks
 * DeviceKit-power
 * Canberra
 * PolicyKit
 * PulseAudio

 I'm going to focus on the following programming languages:

 * C
 * C++
 * Java
 * JavaScript
 * C#
 * Perl
 * Python

 Developer tools I'll be pushing:

 * Anjuta
 * Devhelp
 * Glade
 * Accerciser
 * Nemiver

 On top of this, I would like to have a section where we
 highlight application plugin APIs.  I'll be hunting for
 places where developers can plug into our desktop.  If
 you want your application highlighted, send me an email
 to make sure I don't overlook it.

 I'm going to begin sketching out the content plan for
 the Platform Overview based on this.  If I've forgotten
 something, please tell me.  If you feel strongly that
 anything I mentioned should not be pushed, speak up.

 After the Overview content is planned, I'll begin work
 on planning the introductions.  These are the going to
 be the first thing a lot of new developers see, so we
 have to make them rock.

 Happy hacking.

 --
 Shaun McCance
 http://syllogist.net/

 ___
 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: Platform for Developer Documentation

[Alberto Ruiz]

2010/3/7 Robert Ancell robert.anc...@gmail.com:
 Is soup required now that we have GIO?

GIO doesn't implement an http client at all, yes, soup is definitively needed.

Although I would like to see more integration between Soup and GIO in
the future (like using GMemoryIntputStream instead of Soup.Buffer or
the ability to set a custom OutputStream for the Http client to write
the chunks to).

 On 8 March 2010 08:16, Shaun McCance sha...@gnome.org wrote:
 Hi folks,

 I'm working on what to include in the Platform Overview.
 This affects what gets focused on in the introductions
 and howtos in my developer documentation plan:

 http://live.gnome.org/DocumentationProject/Planning/DeveloperDocs

 I've tried starting this discussion before, but haven't
 gotten a lot of response.  So rather than ask, I'm going
 to propose a list of technologies and see if there are
 any objections.

 I'm taking the big tent approach.  If we're using it,
 and it's not something we consider to be a system library,
 then it's in.  I don't care if it's in the platform, the
 desktop, or the external dependencies.  I want to present
 third-party developers with the most complete development
 platform possible.

 I also want to focus on developer tools.  They should be
 featured heavily when we talk about how to develop for
 Gnome.

 Enough yakking.  Libraries I'm going to push:

 * GTK+
 * GLib (+ GObject, GIO, GSettings)
 * Pango
 * Cairo
 * ATK
 * AT-SPI
 * Clutter
 * PackageKit
 * Tracker
 * Telepathy
 * Evolution Data Server
 * Gnome Keyring
 * GStreamer
 * WebKitGTK+
 * Soup
 * Avahi
 * DBus
 * DeviceKit-disks
 * DeviceKit-power
 * Canberra
 * PolicyKit
 * PulseAudio

 I'm going to focus on the following programming languages:

 * C
 * C++
 * Java
 * JavaScript
 * C#
 * Perl
 * Python

 Developer tools I'll be pushing:

 * Anjuta
 * Devhelp
 * Glade
 * Accerciser
 * Nemiver

 On top of this, I would like to have a section where we
 highlight application plugin APIs.  I'll be hunting for
 places where developers can plug into our desktop.  If
 you want your application highlighted, send me an email
 to make sure I don't overlook it.

 I'm going to begin sketching out the content plan for
 the Platform Overview based on this.  If I've forgotten
 something, please tell me.  If you feel strongly that
 anything I mentioned should not be pushed, speak up.

 After the Overview content is planned, I'll begin work
 on planning the introductions.  These are the going to
 be the first thing a lot of new developers see, so we
 have to make them rock.

 Happy hacking.

 --
 Shaun McCance
 http://syllogist.net/

 ___
 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




-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Shaun McCance]

On Sun, 2010-03-07 at 23:34 +0100, Emilio Pozuelo Monfort wrote:
 On 07/03/10 22:16, Shaun McCance wrote:
  I'm going to focus on the following programming languages:
  
  * C
  * C++
  * Java
  * JavaScript
  * C#
  * Perl
  * Python
 
  I'm going to begin sketching out the content plan for
  the Platform Overview based on this.  If I've forgotten
  something, please tell me.  If you feel strongly that
  anything I mentioned should not be pushed, speak up.
 
 Looks like you forgot Vala.

I actually meant to put Vala in that list, and
honestly forgot.

-- 
Shaun McCance
http://syllogist.net/

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

Re: Platform for Developer Documentation

[Johannes Schmid]

Hi!

 On top of this, I would like to have a section where we
 highlight application plugin APIs.  I'll be hunting for
 places where developers can plug into our desktop.  If
 you want your application highlighted, send me an email
 to make sure I don't overlook it.

Well, would be cool to add the Anjuta plugin API as it is quite complete
(ok, it needs some updates in the development version but I promise to
update those...)

Thanks for putting all this together,
Johannes


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Shaun McCance]

On Sun, 2010-03-07 at 22:32 +, Philip Withnall wrote:
 On Sun, 2010-03-07 at 15:16 -0600, Shaun McCance wrote:
  I'm going to begin sketching out the content plan for
  the Platform Overview based on this.  If I've forgotten
  something, please tell me.  If you feel strongly that
  anything I mentioned should not be pushed, speak up.
 
 What about libnotify, libunique and libxml2? They're fairly commonly
 used, but I'm not sure if we should be pushing them. There's still talk
 of including the functionality of the first two in GTK+/GLib, while
 libxml2 is hardly a shining example of a usable or well-documented
 library.

I think we've generally considered libxml2 to be a system
library lately.

For libnotify, I admit I've been actively avoiding the
discussions about notification systems lately, because
they have a tendency to get unpleasant.

If libunique really can't make it into GLib or GTK+,
then I suppose it's something that should be talked
about.

 What about jhbuild, Alleyoop and D-Feet for applications? jhbuild is
 vital for anyone wanting to build GNOME, Alleyoop is in the same vein as
 Nemiver, and D-Feet should be pushed if you're pushing D-Bus.

I didn't know about Alleyoop, and I agree D-Feet is
a nice tool.  I know I ignored our release sets for
the platform libraries, but for the developer tools
it would actually be really nice if I could follow
that release set.

I think jhbuild is in a different class altogether.
My target audience is people who want to develop with
our platform, not necessarily people who want to work
on Gnome itself.

-- 
Shaun McCance
http://syllogist.net/

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

Re: Platform for Developer Documentation

[Alberto Ruiz]

2010/3/7 Shaun McCance sha...@gnome.org:
 On Sun, 2010-03-07 at 22:32 +, Philip Withnall wrote:
 On Sun, 2010-03-07 at 15:16 -0600, Shaun McCance wrote:
  I'm going to begin sketching out the content plan for
  the Platform Overview based on this.  If I've forgotten
  something, please tell me.  If you feel strongly that
  anything I mentioned should not be pushed, speak up.

 What about libnotify, libunique and libxml2? They're fairly commonly
 used, but I'm not sure if we should be pushing them. There's still talk
 of including the functionality of the first two in GTK+/GLib, while
 libxml2 is hardly a shining example of a usable or well-documented
 library.

 I think we've generally considered libxml2 to be a system
 library lately.

Indeed, although a XML GObject API is long overdue.

 For libnotify, I admit I've been actively avoiding the
 discussions about notification systems lately, because
 they have a tendency to get unpleasant.

 If libunique really can't make it into GLib or GTK+,
 then I suppose it's something that should be talked
 about.

AFAIK ebassi is been working on a GtkApplication class so I think we
should avoid adding things ought to be deprecated.

 What about jhbuild, Alleyoop and D-Feet for applications? jhbuild is
 vital for anyone wanting to build GNOME, Alleyoop is in the same vein as
 Nemiver, and D-Feet should be pushed if you're pushing D-Bus.

 I didn't know about Alleyoop, and I agree D-Feet is
 a nice tool.  I know I ignored our release sets for
 the platform libraries, but for the developer tools
 it would actually be really nice if I could follow
 that release set.

 I think jhbuild is in a different class altogether.
 My target audience is people who want to develop with
 our platform, not necessarily people who want to work
 on Gnome itself.

 --
 Shaun McCance
 http://syllogist.net/

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




-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Javier Jardón]

2010/3/7 Shaun McCance sha...@gnome.org:
 Hi folks,

 I'm working on what to include in the Platform Overview.
 This affects what gets focused on in the introductions
 and howtos in my developer documentation plan:

 http://live.gnome.org/DocumentationProject/Planning/DeveloperDocs

 I've tried starting this discussion before, but haven't
 gotten a lot of response.  So rather than ask, I'm going
 to propose a list of technologies and see if there are
 any objections.

 I'm taking the big tent approach.  If we're using it,
 and it's not something we consider to be a system library,
 then it's in.  I don't care if it's in the platform, the
 desktop, or the external dependencies.  I want to present
 third-party developers with the most complete development
 platform possible.

 I also want to focus on developer tools.  They should be
 featured heavily when we talk about how to develop for
 Gnome.

 Enough yakking.  Libraries I'm going to push:

 * GTK+
 * GLib (+ GObject, GIO, GSettings)
 * Pango
 * Cairo
 * ATK
 * AT-SPI
 * Clutter
 * PackageKit
 * Tracker
 * Telepathy
 * Evolution Data Server
 * Gnome Keyring
 * GStreamer
 * WebKitGTK+
 * Soup
 * Avahi
 * DBus
 * DeviceKit-disks

This is now udisks

 * DeviceKit-power

This is now upower

 * Canberra
 * PolicyKit
 * PulseAudio

What about:
 - libgda [1] to access databases
 - libgee [2] as a collection library.

Also, I think would be great mention some of the available libraries
to interact with the WEB [3]

 Developer tools I'll be pushing:

 * Anjuta
 * Devhelp
 * Glade
 * Accerciser
 * Nemiver

I think talk about parasite [4] (It's like firebug but for GTK+
applications) would be a good idea

Regards,


[1] http://www.gnome-db.org/
[2] http://live.gnome.org/Libgee
[3] http://live.gnome.org/OnlineIntegration
[4] http://chipx86.github.com/gtkparasite/


-- 
Javier Jardón Cabezas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[Diego Escalante Urrelo]

El dom, 07-03-2010 a las 15:16 -0600, Shaun McCance escribió:
 Hi folks,
 
 I'm working on what to include in the Platform Overview.
 This affects what gets focused on in the introductions
 and howtos in my developer documentation plan:
 

I just wanted to high five Shaun for JFDI. I owe you $drink.

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

Re: Platform

[Stefan Kost]

Lennart Poettering schrieb:
 On Mon, 18.05.09 22:39, Stefan Kost (enso...@hora-obscura.de) wrote:
 
 Avahi -- Service discovery.  This is used in quite a few
 places.  I know some people in the past had talked about
 having a simple wrapper in GLib.  How much do we push it?
 
 Avahi has been shipping with a GObject API contributed by Sjoerd since
 quite some time. It's established and maintained. This should
 definitely be pushed.
 
 Now that apple has closed the whole bonjour stack, I would prefer to build on
 upnp. We have gupnp, which is actively developed and fitting nicely here.
 
 As mentioned by other folks this is nonsense.
 
Sorry for my misinformed mail and many thanks for this enlightening and
informative correction.

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

Re: Platform

[Lennart Poettering]

On Mon, 18.05.09 22:39, Stefan Kost (enso...@hora-obscura.de) wrote:

  Avahi -- Service discovery.  This is used in quite a few
  places.  I know some people in the past had talked about
  having a simple wrapper in GLib.  How much do we push it?

Avahi has been shipping with a GObject API contributed by Sjoerd since
quite some time. It's established and maintained. This should
definitely be pushed.

 Now that apple has closed the whole bonjour stack, I would prefer to build on
 upnp. We have gupnp, which is actively developed and fitting nicely here.

As mentioned by other folks this is nonsense.

mDNS/DNS-SD is certainly as open as UPNP. In fact you could even argue that
it is more open since it was submitted to become an IETF RFC which didn't
happen for UPnP -- and is very unlikely to ever happen.

The initial Apple implementation of mDNS/DNS, which was Rendezvous
(later renamed to Bonjour) was licensed under APSL -- which is not a
Free Software license. The main reason I wrote Avahi was the broken
license of Bonjour. Avahi is fully LGPL and due to that became *the*
mDNS/DNS-SD stack on free systems. Eventually Apple acknowelegded that
they fucked up there and relicensed Bonjour to the Apache
License. Which is certainly a much better choice and makes it Free
Software, but isn't 100% satisfactory either since it is GPL2
incompatible. (though this doesn't matter much in reality).

These days Avahi does many things better than Bonjour but there are a
handful of things Bonjour does Avahi can't. However, the Apple guys
publicly acknowledge that Avahi is the better stack ;-)

So, in summary: mDNS/DNS-SD *is* absolutely open. It has very high
quality documentation/specification. And it has two complete 100% Free
Software implementations. What else do you need to declare something
Open?

Now, there are a two sour points:

1) If you want to use the Bonjour trademark you need to sign a
contract with Apple. Luckily, this doesn't matter at all to us, since
we can call the technology mDNS/DNS-SD and our implementation of that
Avahi. We don't even use any of the code from the original Bonjour
project. (UPnP has a similar trademark mess with DLNA AFAIU)

2) What Apple really fucked up are two of the protocols that they use
on top of mDNS/DNS-SD, more specifically DMAP (better known as
DAAP/DPAP) and RAOP. The former is a protocol for sharing music repos
across local networks. The latter is a protocol for sending audio to
remote speakers (i.e. Apple Airport base stations that have audio
connectors.) Apple uses cryptography to dongle DMAP and RAOP clients
and servers together. Probably to please record companies. It's some
crypto that hasn't been fully broken yet. One side of the key pairs of
both RAOP and DMAP have been recovered, the other one hasn't. Which
means you can implement a RAOP client and a DMAP server right
now. However implementing a RAOP server or a DMAP client that iTunes
would accept as valid is not possible. Which sucks big time.

Now, on top of UPnP we have UPnP A/V which does very similar things as
DMAP and RAOP. A UPnP A/V MediaRenderer plays about the same role as
an RAOP server. And a UPnP A/V MediaServer plays about the same role
as DMAP server. UPnP A/V is open and documented, no dongling takes
place. Which is the reason why RAOP and DMAP are not nearly as popular
on Linux as they used to be. OTOH UPnP A/V is now widely implemented
and there's even a lot of explicit hardware for it. Apple came first
with both DMAP and RAOP. And they were in a great position. But they
fucked it up due to their stupid dongling, and everyone went for the
open alternative.

But again, mDNS/DNS-SD is open. It's just DMAP/RAOP that is not. But
these two pairs of technologies are not directly related and should be
seen independantly. Especiually since Avahi does not implement
DMAP/RAOP and nobody has suggested inclusion of a DMAP/RAOP library
into the platform. There are many other protocols that can be used on
top of Avahi that make Avahi very very useful.

On a purely technical level I think that mDNS/DNS-SD as well as
DMA/RAOP are much better designed than UPnP/UPnP A/V. i.e. mDNS is
very careful about caching to minimize traffic on the network. In fact
the largest part of the spec is about the elaborate caching
scheme. UPnP otoh is very chatty. RAOP also has all kinds of nice
features like jack sensing, dB volume scaling and so on. UPnP A/V is
much more limited there -- but it does have other benefits. ... but
hey I don't think it makes much sense to compare both technologies in
that much detail here, and of course I am biased since I wrote
Avahi. And I don't want to piss off Zeeshan...  ;-)

But let me say this: right now if you want to stay compatible with
specific third party software or hardware the choice between UPNP and
mDNS/DNS-SD is not up to you. Which is why both technologies have
their validity even if they share a bit functionality. -- If you start
a new project/protocol however I'd probably

Re: Platform

[Lennart Poettering]

On Tue, 19.05.09 12:00, Bastien Nocera (had...@hadess.net) wrote:

 
 On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:
  Shaun McCance schrieb:
 snip
   Avahi -- Service discovery.  This is used in quite a few
   places.  I know some people in the past had talked about
   having a simple wrapper in GLib.  How much do we push it?
   
  Now that apple has closed the whole bonjour stack,
 
 Huh? Bonjour (or Rendezvous as it used to be called) was BSD licensed,
 but it doesn't matter to us as we have our own stack in Avahi.
 
 Citation needed here.

Bonjour was initially APSL licensed. They switched to Apache then. It
never was BSD licensed, except for a tiny header file.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Lennart Poettering]

On Thu, 21.05.09 21:30, Stefan Kost (enso...@hora-obscura.de) wrote:

 
 Bastien Nocera schrieb:
  On Tue, 2009-05-19 at 17:15 +0300, Stefan Kost wrote:
  Bastien Nocera schrieb:
  On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:

  Shaun McCance schrieb:
  
  snip

  Avahi -- Service discovery.  This is used in quite a few
  places.  I know some people in the past had talked about
  having a simple wrapper in GLib.  How much do we push it?
 

  Now that apple has closed the whole bonjour stack,
  
  Huh? Bonjour (or Rendezvous as it used to be called) was BSD licensed,
  but it doesn't matter to us as we have our own stack in Avahi.
 
  Citation needed here.

  See my previous email.
  
  The Wikipedia article? There's nothing there saying Apple closed the
  Bonjour stack.
  
  snip
  You might be confusing mDNS and service discovery with the protocols
  implemented on top of it. We want to use both UPNP and mDNS for
  interoperability purposes, but I don't see the point in re-coding mDNS
  applications to use UPNP instead
  I just pointed to the legal situation. I know that those are two
  different things and idealy we support them both as needed.
  
  A trademark problem? Why is that an issue to us what Apple calls their
  mDNS stack?
  
  I still don't understand what you're worried about...
  
 this is from lennarts blog:
 http://0pointer.de/blog/projects/bonjour-apache-license.html
 would be good if avahi developers could comment here.

This blog posting of mine refers to the Bonjour software. Not an
abstract technology.

The license of Bonjour (the software) does not matter to us at
all. Since we have an independant implementation called Avahi which
shares no code with Bonjour (the software).

The license of Bonjour (the trademark) does not matter to us at all
either since we don't use that for anything.

All that should matter to us are mDNS/DNS-SD (the technology) and
Avahi (the software) both of which are open and free.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Hubert Figuiere]

On 05/26/2009 08:48 PM, Lennart Poettering wrote:

The initial Apple implementation of mDNS/DNS, which was Rendezvous
(later renamed to Bonjour) was licensed under APSL -- which is not a
Free Software license.


Not to remove any argument, but for the sake of accuracy, it should be 
noted that APSL 2.0 is Free Software, according to the FSF:

  http://www.gnu.org/philosophy/apsl.html

Albeit APSL 2.0 is not compatible with the GPL (like the Apache v2 
license isn't compatible with GPLv2), which is a problem when it comes 
to GNOME.



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

Re: Platform

[Lennart Poettering]

On Thu, 21.05.09 11:36, Matej Cepl (mc...@redhat.com) wrote:

 Stefan Kost, Mon, 18 May 2009 22:39:21 +0300:
  Now that apple has closed the whole bonjour stack, I would prefer to
  build on upnp. We have gupnp, which is actively developed and fitting
  nicely here.
 
 a) Nothing can be more closed than closed ... which Microsoft's UPNP
 IIRC.

Not true. For both technologies there is freely available
documentation. The UPnP docs suck ass though, apparently. ;-)

 b) UPNP is known security threat and the only sensible advice to
 anybody caring a bit about security is to switch it off (on Windows, don't 
 know 
 the situation on Linux).

I am pretty sure that Avahi is much more careful when it comes to
security than the average upnp implementation, but generally the lower
layers of upnp and mdns are equally safe or unsafe.

The bad security record of UPnP stems from UPnP IGD which allows you
to reconfigure routers and does provide no authentication. But if
you'd build a similar technology on top of mDNS/DNS-SD it wouldn't be
any better.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Lennart Poettering]

On Tue, 26.05.09 21:03, Hubert Figuiere (h...@figuiere.net) wrote:


 On 05/26/2009 08:48 PM, Lennart Poettering wrote:
 The initial Apple implementation of mDNS/DNS, which was Rendezvous
 (later renamed to Bonjour) was licensed under APSL -- which is not a
 Free Software license.

 Not to remove any argument, but for the sake of accuracy, it should be  
 noted that APSL 2.0 is Free Software, according to the FSF:
   http://www.gnu.org/philosophy/apsl.html

 Albeit APSL 2.0 is not compatible with the GPL (like the Apache v2  
 license isn't compatible with GPLv2), which is a problem when it comes  
 to GNOME.

Hmm, Bonjour was licensed under the original APSL license when it was
released.  Also I think the Debian folks still don't consider it
DFSG-free...

But anyway, I guess it doesn't matter anymore.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

mDNS vs Upnp was Re: Platform

[Christian Fredrik Kalager Schaller]

I can't help but feel that this discussion about Avahi versus gupnp is
rather construed. Most application developers will go looking for either
of these technologies because they want to interoperate with a specific
set of non-GNOME devices. If you want your video player to be able to
send video directly to a DLNA certified TV for instance you probably
couldn't care less whether Avahi is the officially blessed stack for
these sort of things, cause Avahi doesn't do what you need it to do. And
the other way around if you are trying to integrate with Apple hardware
you wouldn't give a damn if gupnp was the official stack for these sort
of things as it wouldn't do what you need it to.

The only usecase where a developer might care which one is 'officially
blessed' would be in the GNOME to GNOME usecase, but I honestly believe
that is a tiny minority of the usecases.

Christian

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

Re: mDNS vs Upnp was Re: Platform

[Stefan Kost]

Christian Fredrik Kalager Schaller schrieb:
 I can't help but feel that this discussion about Avahi versus gupnp is
 rather construed. Most application developers will go looking for either
 of these technologies because they want to interoperate with a specific
 set of non-GNOME devices. If you want your video player to be able to
 send video directly to a DLNA certified TV for instance you probably
 couldn't care less whether Avahi is the officially blessed stack for
 these sort of things, cause Avahi doesn't do what you need it to do. And
 the other way around if you are trying to integrate with Apple hardware
 you wouldn't give a damn if gupnp was the official stack for these sort
 of things as it wouldn't do what you need it to.

 The only usecase where a developer might care which one is 'officially
 blessed' would be in the GNOME to GNOME usecase, but I honestly believe
 that is a tiny minority of the usecases.

 Christian
   
yes. So what about mentioning both avahi  gupnp in that sections?

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

Re: Platform

[Matej Cepl]

Stefan Kost, Mon, 18 May 2009 22:39:21 +0300:
 Now that apple has closed the whole bonjour stack, I would prefer to
 build on upnp. We have gupnp, which is actively developed and fitting
 nicely here.

a) Nothing can be more closed than closed ... which Microsoft's UPNP IIRC.
b) UPNP is known security threat and the only sensible advice to anybody 
caring a bit about security is to switch it off (on Windows, don't know 
the situation on Linux).
c) Have Apple threatened Lennart to stop him from developing avahi? Or 
what is the problem?

Matěj

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

Re: Platform

[Ross Burton]

On Thu, 2009-05-21 at 11:36 +, Matej Cepl wrote:
 Stefan Kost, Mon, 18 May 2009 22:39:21 +0300:
  Now that apple has closed the whole bonjour stack, I would prefer to
  build on upnp. We have gupnp, which is actively developed and fitting
  nicely here.
 
 a) Nothing can be more closed than closed ... which Microsoft's UPNP IIRC.

IIRC, UPnP is as closed as Zeroconf: not at all.  Both are
implementatations of open specifications.  Unless someone can produce
pantents there is no reason to consider either protocols closed.

 b) UPNP is known security threat and the only sensible advice to anybody 
 caring a bit about security is to switch it off (on Windows, don't know 
 the situation on Linux).

Well, it's a security threat if you use it for things which should be
secure.  Don't. (this means turning off upnp on your router if you care
about this).

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Timothy P. Horton]

On 2009.05.21, at 07:36, Matej Cepl wrote:


Stefan Kost, Mon, 18 May 2009 22:39:21 +0300:

Now that apple has closed the whole bonjour stack, I would prefer to
build on upnp. We have gupnp, which is actively developed and fitting
nicely here.


a) Nothing can be more closed than closed ... which Microsoft's UPNP  
IIRC.
b) UPNP is known security threat and the only sensible advice to  
anybody
caring a bit about security is to switch it off (on Windows, don't  
know

the situation on Linux).
c) Have Apple threatened Lennart to stop him from developing avahi? Or
what is the problem?


I, too, am interested to know what this means. As far as I know (and http://developer.apple.com/opensource/internet/bonjour.html 
 agrees with me), Apple's implementation of Bonjour is still  
published under the Apache License... I do notice that the last  
release was three years ago, and that their CVS server (yikes) seems  
to be down (I wanted to check out the code and see if anything had  
been pushed there in the last 3 years), perhaps that's what he's  
referring to?



Matěj

___
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: Platform

[Stefan Kost]

Bastien Nocera schrieb:
 On Tue, 2009-05-19 at 17:15 +0300, Stefan Kost wrote:
 Bastien Nocera schrieb:
 On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:
   
 Shaun McCance schrieb:
 
 snip
   
 Avahi -- Service discovery.  This is used in quite a few
 places.  I know some people in the past had talked about
 having a simple wrapper in GLib.  How much do we push it?

   
 Now that apple has closed the whole bonjour stack,
 
 Huh? Bonjour (or Rendezvous as it used to be called) was BSD licensed,
 but it doesn't matter to us as we have our own stack in Avahi.

 Citation needed here.
   
 See my previous email.
 
 The Wikipedia article? There's nothing there saying Apple closed the
 Bonjour stack.
 
 snip
 You might be confusing mDNS and service discovery with the protocols
 implemented on top of it. We want to use both UPNP and mDNS for
 interoperability purposes, but I don't see the point in re-coding mDNS
 applications to use UPNP instead
 I just pointed to the legal situation. I know that those are two
 different things and idealy we support them both as needed.
 
 A trademark problem? Why is that an issue to us what Apple calls their
 mDNS stack?
 
 I still don't understand what you're worried about...
 
this is from lennarts blog:
http://0pointer.de/blog/projects/bonjour-apache-license.html
would be good if avahi developers could comment here.

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

Re: Platform

[Matteo Settenvini]

Il giorno gio, 21/05/2009 alle 21.30 +0300, Stefan Kost ha scritto:
 Bastien Nocera schrieb:
  On Tue, 2009-05-19 at 17:15 +0300, Stefan Kost wrote:
  
  snip
  You might be confusing mDNS and service discovery with the protocols
  implemented on top of it. We want to use both UPNP and mDNS for
  interoperability purposes, but I don't see the point in re-coding mDNS
  applications to use UPNP instead
  I just pointed to the legal situation. I know that those are two
  different things and idealy we support them both as needed.
  
  A trademark problem? Why is that an issue to us what Apple calls their
  mDNS stack?
  
  I still don't understand what you're worried about...
  
 this is from lennarts blog:
 http://0pointer.de/blog/projects/bonjour-apache-license.html
 would be good if avahi developers could comment here.
 
 Stefan

As I read this: Apple's implementation is under the Apache license,
which isn't particularly good, *SO* Avahi itself has been rewritten
using the LGPL, and offers much better integration with the GNU/Linux
stack (for example, DBus support...). 

This means there're no compatibility problems with Avahi and other free
(as in speech) software around.

This I got by reading http://avahi.org/. 

To sum it up: the mDNS specification is there to implement, Apple
released Bonjour with the Apache license, Avahi implements it using the
LGPL.

Maybe I'm missing something?

Matteo


signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Stefan Kost]

Shaun McCance schrieb:
 On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:
   
 Shaun McCance schrieb:
 
 Avahi -- Service discovery.  This is used in quite a few
 places.  I know some people in the past had talked about
 having a simple wrapper in GLib.  How much do we push it?

   
 Now that apple has closed the whole bonjour stack, I would prefer to build on
 upnp. We have gupnp, which is actively developed and fitting nicely here.
 

 Closed in what way?  Is UPnP any more open?  What do we have
 using Zeroconf right now?  What do we have using UPnP?  What
 things do we get to choose what to use, versus technologies
 that we just have to conform to?
   
http://en.wikipedia.org/wiki/Bonjour_(software)
I hope that someone else can speak up too - I am not an expert here at
all. One thing that zeroconf and upnp have in common is service discovery.

Stefan

 And what are the chances that we could get a wrapper for
 either or both of these in GLib?

 --
 Shaun


   

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

Re: Platform

[Patryk Zawadzki]

On Mon, May 18, 2009 at 9:39 PM, Stefan Kost enso...@hora-obscura.de wrote:
 Now that apple has closed the whole bonjour stack, I would prefer to build on
 upnp. We have gupnp, which is actively developed and fitting nicely here.

Now I don't want to make political statements, it's pure software
engineering. Be it closed or open, we have a working Avahi
implementation of the Bonjour stack. Also if you don't want streaming
but only care about service announcing and discovery, Avahi is
massively easier to use (and for example comes with nice python
bindings).

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

Re: Platform

[Bastien Nocera]

On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:
 Shaun McCance schrieb:
snip
  Avahi -- Service discovery.  This is used in quite a few
  places.  I know some people in the past had talked about
  having a simple wrapper in GLib.  How much do we push it?
  
 Now that apple has closed the whole bonjour stack,

Huh? Bonjour (or Rendezvous as it used to be called) was BSD licensed,
but it doesn't matter to us as we have our own stack in Avahi.

Citation needed here.

  I would prefer to build on
 upnp.

UPNP is overly complicated for service discovery.

  We have gupnp, which is actively developed and fitting nicely here.

mDNS as a service discovery tool is much better than UPNP, and the tools
are more mature.

You might be confusing mDNS and service discovery with the protocols
implemented on top of it. We want to use both UPNP and mDNS for
interoperability purposes, but I don't see the point in re-coding mDNS
applications to use UPNP instead.

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

Re: Platform

[Stefan Kost]

Bastien Nocera schrieb:
 On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:
   
 Shaun McCance schrieb:
 
 snip
   
 Avahi -- Service discovery.  This is used in quite a few
 places.  I know some people in the past had talked about
 having a simple wrapper in GLib.  How much do we push it?

   
 Now that apple has closed the whole bonjour stack,
 

 Huh? Bonjour (or Rendezvous as it used to be called) was BSD licensed,
 but it doesn't matter to us as we have our own stack in Avahi.

 Citation needed here.
   

See my previous email.
   
  I would prefer to build on
 upnp.
 

 UPNP is overly complicated for service discovery.

   
  We have gupnp, which is actively developed and fitting nicely here.
 

 mDNS as a service discovery tool is much better than UPNP, and the tools
 are more mature.

 You might be confusing mDNS and service discovery with the protocols
 implemented on top of it. We want to use both UPNP and mDNS for
 interoperability purposes, but I don't see the point in re-coding mDNS
 applications to use UPNP instead

I just pointed to the legal situation. I know that those are two
different things and idealy we support them both as needed.

Stefan

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

Re: Platform

[Bastien Nocera]

On Tue, 2009-05-19 at 17:15 +0300, Stefan Kost wrote:
 Bastien Nocera schrieb:
  On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:

  Shaun McCance schrieb:
  
  snip

  Avahi -- Service discovery.  This is used in quite a few
  places.  I know some people in the past had talked about
  having a simple wrapper in GLib.  How much do we push it?
 

  Now that apple has closed the whole bonjour stack,
  
 
  Huh? Bonjour (or Rendezvous as it used to be called) was BSD licensed,
  but it doesn't matter to us as we have our own stack in Avahi.
 
  Citation needed here.

 
 See my previous email.

The Wikipedia article? There's nothing there saying Apple closed the
Bonjour stack.

snip
  You might be confusing mDNS and service discovery with the protocols
  implemented on top of it. We want to use both UPNP and mDNS for
  interoperability purposes, but I don't see the point in re-coding mDNS
  applications to use UPNP instead
 
 I just pointed to the legal situation. I know that those are two
 different things and idealy we support them both as needed.

A trademark problem? Why is that an issue to us what Apple calls their
mDNS stack?

I still don't understand what you're worried about...

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

Re: Platform

[Zeeshan Ali (Khattak)]

On Tue, May 19, 2009 at 2:00 PM, Bastien Nocera had...@hadess.net wrote:
 On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:
 Shaun McCance schrieb:
 snip
  Avahi -- Service discovery.  This is used in quite a few
  places.  I know some people in the past had talked about
  having a simple wrapper in GLib.  How much do we push it?
 
 Now that apple has closed the whole bonjour stack,

 Huh? Bonjour (or Rendezvous as it used to be called) was BSD licensed,
 but it doesn't matter to us as we have our own stack in Avahi.

 Citation needed here.

  I would prefer to build on
 upnp.

 UPNP is overly complicated for service discovery.

   Actually that is pretty stright forward but it does something (not
so) stupid for that: HTTP over UDP. That issue IMO is only of academic
interest though.

-- 
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

Re: Platform

[Zeeshan Ali (Khattak)]

On Tue, May 19, 2009 at 1:59 PM, Patryk Zawadzki pat...@pld-linux.org wrote:
 On Mon, May 18, 2009 at 9:39 PM, Stefan Kost enso...@hora-obscura.de wrote:
 Now that apple has closed the whole bonjour stack, I would prefer to build on
 upnp. We have gupnp, which is actively developed and fitting nicely here.

 Now I don't want to make political statements, it's pure software
 engineering. Be it closed or open, we have a working Avahi
 implementation of the Bonjour stack. Also if you don't want streaming
 but only care about service announcing and discovery, Avahi is
 massively easier to use (and for example comes with nice python
 bindings).

  Service discovery is pretty easy with UPnP as well when using GUPnP.
All you have to do is to create one object and listen to signals for
device/service (un)availability. Unfortunately, we don't have python
bindings but keeping in mind gupnp is mostly gobject-based, it
shouldn't be a challenge to implement.

  One important thing to keep in mind when comparing avahi/mDNS/etc
with UPnP is that UPnP is much more than addressing and discovery:
Zeroconf defines standards for the addressing and discovery of
services on a network but do no define any means for description[1],
control, event notification and presentation.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1]  We all know how useful D-Bus introspection with d-feet is, the
usefulness of UPnP description combined with gupnp-universal-cp is
quite the same.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Stefan Kost]

Shaun McCance schrieb:
 Hey folks,
 
 I'm taking a hard look at the Platform Overview and how we
 can improve our message to ISDs through better documentation.
 Our release sets, unfortunately, don't really reflect what we
 really recommend to developers.  That role has more or less
 been delegated to the Platform Overview.
 
 The problem is that what's in the Platform Overview is based
 entirely on what I happened to think was worth mentioning at
 some point.  I should not be the arbiter of our platform.
 
 I would like to get people's opinions on what technologies
 we should be pushing.  I'm interested both in the here and
 now and in what people think the Gnome 3 message should be.
 
 I've organized my thoughts into three categories: Platform
 contains technologies that are currently in our Developer
 Platform release; Recommended contains thing that we seem
 to agree we should push, but are either in the Desktop
 release or just in our external dependencies; and Others
 contains stuff that I think is cool and could be part of
 our core offering some time in the indeterminate future.
 
 The list is what came to mind as I was writing this email.
 Please feel free to discuss libraries I forgot.
 
 
 Platform
 
 
 GTK+ -- The core of how we make graphical applications.
 
 Pango -- Internationalized text rendering system.  You
 love it and you know it.
 
 GLib -- The foundation for pretty much everything we do.
 
 GIO -- Part of GLib, but worth a separate mention in the
 Platform Overview.
 
 GConf -- Configuration system.  There is talk of a new
 system (see below).  But I think it's obvious that we need
 to be pushing something here.  So as long as GConf is what
 we have, it's what we push.
 
 ATK -- Accessibility toolkit.  Used by GTK+.  Should be
 used by anything else that does UIs.
 
 
 Recommended
 ===
 
 Cairo -- Incredible drawing library, used by GTK+.  There
 seems to be general agreement that developers should use
 Cairo when they need to do custom drawing.
 
 GStreamer -- All things multimedia.  I don't think there's
 any argument against GStreamer being the Gnome-blessed way
 to do multimedia.
 
 D-Bus -- Inter-process messaging system.  Lots of stuff is
 built on it.  How much do we want to push it directly?
 
 Avahi -- Service discovery.  This is used in quite a few
 places.  I know some people in the past had talked about
 having a simple wrapper in GLib.  How much do we push it?
 
Now that apple has closed the whole bonjour stack, I would prefer to build on
upnp. We have gupnp, which is actively developed and fitting nicely here.

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

Re: Platform

[Stefan Kost]

Shaun McCance schrieb:
 On Tue, 2009-05-05 at 14:05 -0500, Shaun McCance wrote:
 Hey folks,

 I'm taking a hard look at the Platform Overview
 
 http://library.gnome.org/devel/platform-overview/stable/index.html
 
 For those who don't know.

It would be nice if we could get more images like this one in
http://library.gnome.org/devel/platform-overview/stable/graphics.html.en

No fancy UML, just on that level. Imho this makes the document more credible and
 improves the hedonistic experience for the reader :)

For multimedia aka GSTreamer we have this one
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-gstreamer.html

do we want them all in the same style. if the UI one is available as svg, it
should not be too diffcult to redraw the gst one.

Stefan

 
 --
 Shaun
 
 
 ___
 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: Platform

[Shaun McCance]

On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:
 Shaun McCance schrieb:
  Avahi -- Service discovery.  This is used in quite a few
  places.  I know some people in the past had talked about
  having a simple wrapper in GLib.  How much do we push it?
  
 Now that apple has closed the whole bonjour stack, I would prefer to build on
 upnp. We have gupnp, which is actively developed and fitting nicely here.

Closed in what way?  Is UPnP any more open?  What do we have
using Zeroconf right now?  What do we have using UPnP?  What
things do we get to choose what to use, versus technologies
that we just have to conform to?

And what are the chances that we could get a wrapper for
either or both of these in GLib?

--
Shaun


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

Re: Platform

[Shaun McCance]

On Mon, 2009-05-18 at 22:49 +0300, Stefan Kost wrote:
 Shaun McCance schrieb:
  On Tue, 2009-05-05 at 14:05 -0500, Shaun McCance wrote:
  Hey folks,
 
  I'm taking a hard look at the Platform Overview
  
  http://library.gnome.org/devel/platform-overview/stable/index.html
  
  For those who don't know.
 
 It would be nice if we could get more images like this one in
 http://library.gnome.org/devel/platform-overview/stable/graphics.html.en
 
 No fancy UML, just on that level. Imho this makes the document more credible 
 and
  improves the hedonistic experience for the reader :)
 
 For multimedia aka GSTreamer we have this one
 http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-gstreamer.html
 
 do we want them all in the same style. if the UI one is available as svg, it
 should not be too diffcult to redraw the gst one.

Yeah, I was talking to Andreas about this the other day.
It's definitely something worth doing.  But planning the
content is step 1.  Diagrams are like step 7.

--
Shaun


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

Re: Platform

[Ross Burton]

On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:
 Now that apple has closed the whole bonjour stack, I would prefer to build on
 upnp. We have gupnp, which is actively developed and fitting nicely here.

I'm very curious as to what this closing of the bonjour stack is: even
if they closed their Bonjour implementation the specifications are
public (interestingly the Internet Draft expired yesterday):

http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt

Whilst I'm a maintainer of GUPnP and think it's the best solution we
have for interoperating with other UPnP devices (of which they are many
in the wild), I really do think it's an ugly specification which hasn't
had any recent development.  I also notice that Windows Vista includes
something I've forgotten the name of which they basically call the
successor to UPnP...

The two technologies are pretty different.

mDNS gives you name resolution and by extension (via cunning use of DNS)
service lookups, i.e. what printers are here.  At this point it stops
caring and you use application-specific protocols: XMPP for link-local
chat, IPP/HTTP for printing, and so on.  Generally mDNS is used to
announce an existing service, such as the location of an existing IPP
print queue, or SSH server, or HTTP server.  Because mDNS doesn't care
what you do after discovery, security is not it's problem.

UPnP doesn't do name resolution, but does do service discovery.
Introspection of services and invocation of remote method calls is also
part of UPnP, invocation is done via everyone's favorite RPC protocol,
SOAP.  The UPnP specifications cover a large number of services
(internet gateway devices, media servers, scanners, printers, security
cameras, lighting and so on) but I've only ever seen IGDs and media
servers in the wild.  Security is non-existent, any process (including
Flash in a web page) can make UPnP calls and  (say) open ports on your
router.

Personally speaking, if you want to do basic service
announcement/discovery and you already have a good protocol which works
(say HTTP or XMPP) then I'd recommend starting with mDNS.  If you want
to interoperate with existing devices (such as routers and media
servers) then using UPnP is the only solution, because I don't know of a
mDNS equivalent for the IGD magic and Apple are working very hard at
stopping you from using DAAP/DPAP on a Mac.

This mail turned out to be a bit longer and rambling than I was hoping,
but the executive summary is this: at present, both are required,
depending on the situation.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Felipe Contreras]

On Tue, May 19, 2009 at 12:52 AM, Ross Burton r...@burtonini.com wrote:
 On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:
 Now that apple has closed the whole bonjour stack, I would prefer to build on
 upnp. We have gupnp, which is actively developed and fitting nicely here.

 I'm very curious as to what this closing of the bonjour stack is: even
 if they closed their Bonjour implementation the specifications are
 public (interestingly the Internet Draft expired yesterday):

 http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt

 Whilst I'm a maintainer of GUPnP and think it's the best solution we
 have for interoperating with other UPnP devices (of which they are many
 in the wild), I really do think it's an ugly specification which hasn't
 had any recent development.  I also notice that Windows Vista includes
 something I've forgotten the name of which they basically call the
 successor to UPnP...

 The two technologies are pretty different.

 mDNS gives you name resolution and by extension (via cunning use of DNS)
 service lookups, i.e. what printers are here.  At this point it stops
 caring and you use application-specific protocols: XMPP for link-local
 chat, IPP/HTTP for printing, and so on.  Generally mDNS is used to
 announce an existing service, such as the location of an existing IPP
 print queue, or SSH server, or HTTP server.  Because mDNS doesn't care
 what you do after discovery, security is not it's problem.

 UPnP doesn't do name resolution, but does do service discovery.
 Introspection of services and invocation of remote method calls is also
 part of UPnP, invocation is done via everyone's favorite RPC protocol,
 SOAP.  The UPnP specifications cover a large number of services
 (internet gateway devices, media servers, scanners, printers, security
 cameras, lighting and so on) but I've only ever seen IGDs and media
 servers in the wild.  Security is non-existent, any process (including
 Flash in a web page) can make UPnP calls and  (say) open ports on your
 router.

 Personally speaking, if you want to do basic service
 announcement/discovery and you already have a good protocol which works
 (say HTTP or XMPP) then I'd recommend starting with mDNS.  If you want
 to interoperate with existing devices (such as routers and media
 servers) then using UPnP is the only solution, because I don't know of a
 mDNS equivalent for the IGD magic and Apple are working very hard at
 stopping you from using DAAP/DPAP on a Mac.

 This mail turned out to be a bit longer and rambling than I was hoping,
 but the executive summary is this: at present, both are required,
 depending on the situation.

Why are we discussing UPnP vs mDNS? Isn't it like discussing USB vs
Firewire? Ideally both should be supported.

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

Re: Platform

[Shaun McCance]

On Tue, 2009-05-19 at 01:31 +0300, Felipe Contreras wrote:
 On Tue, May 19, 2009 at 12:52 AM, Ross Burton r...@burtonini.com wrote:
  On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote:
  Now that apple has closed the whole bonjour stack, I would prefer to build 
  on
  upnp. We have gupnp, which is actively developed and fitting nicely here.
 
  I'm very curious as to what this closing of the bonjour stack is: even
  if they closed their Bonjour implementation the specifications are
  public (interestingly the Internet Draft expired yesterday):
 
  http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt
 
  Whilst I'm a maintainer of GUPnP and think it's the best solution we
  have for interoperating with other UPnP devices (of which they are many
  in the wild), I really do think it's an ugly specification which hasn't
  had any recent development.  I also notice that Windows Vista includes
  something I've forgotten the name of which they basically call the
  successor to UPnP...
 
  The two technologies are pretty different.
 
  mDNS gives you name resolution and by extension (via cunning use of DNS)
  service lookups, i.e. what printers are here.  At this point it stops
  caring and you use application-specific protocols: XMPP for link-local
  chat, IPP/HTTP for printing, and so on.  Generally mDNS is used to
  announce an existing service, such as the location of an existing IPP
  print queue, or SSH server, or HTTP server.  Because mDNS doesn't care
  what you do after discovery, security is not it's problem.
 
  UPnP doesn't do name resolution, but does do service discovery.
  Introspection of services and invocation of remote method calls is also
  part of UPnP, invocation is done via everyone's favorite RPC protocol,
  SOAP.  The UPnP specifications cover a large number of services
  (internet gateway devices, media servers, scanners, printers, security
  cameras, lighting and so on) but I've only ever seen IGDs and media
  servers in the wild.  Security is non-existent, any process (including
  Flash in a web page) can make UPnP calls and  (say) open ports on your
  router.
 
  Personally speaking, if you want to do basic service
  announcement/discovery and you already have a good protocol which works
  (say HTTP or XMPP) then I'd recommend starting with mDNS.  If you want
  to interoperate with existing devices (such as routers and media
  servers) then using UPnP is the only solution, because I don't know of a
  mDNS equivalent for the IGD magic and Apple are working very hard at
  stopping you from using DAAP/DPAP on a Mac.
 
  This mail turned out to be a bit longer and rambling than I was hoping,
  but the executive summary is this: at present, both are required,
  depending on the situation.
 
 Why are we discussing UPnP vs mDNS? Isn't it like discussing USB vs
 Firewire? Ideally both should be supported.

This entire thread is not about what we should be capable
of interacting with.  It's about what we want to present
to third-party developers as our platform.

Say a game developer comes along and wants a way for his
game to find other instances of itself on the local network.
What are we recommending?

I don't have all the answers to these questions.

--
Shaun


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

Re: Platform

[Javi]

2009/5/18 Ross Burton r...@burtonini.com:

 Whilst I'm a maintainer of GUPnP and think it's the best solution we
 have for interoperating with other UPnP devices (of which they are many
 in the wild), I really do think it's an ugly specification which hasn't
 had any recent development.  I also notice that Windows Vista includes
 something I've forgotten the name of which they basically call the
 successor to UPnP...


Perhaps you are referring to DPWS [1] or DLNA [2].
For the second there is a good implementation here [3]

[1] http://en.wikipedia.org/wiki/Devices_Profile_for_Web_Services
[2] http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance
[3] http://coherence.beebits.net/

-- 
Javier Jardón Cabezas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME 3.0 Platform cleanup status

[Andre Klapper]

Ahoj,

this is a status report refering about the aims listed at
http://live.gnome.org/TwoPointTwentyseven .

Statistics refer to http://www.gnome.org/~fpeters/299.html .
Note that http://www.gnome.org/~fpeters/299.html does not yet cover GTK
+/GLib Single includes and GSEAL.

Followups/corrections//whatever welcome.

-andre


=
ZERO modules with Glib-Deprecated-Symbols
=
COMPLETED.
Thanks to Thomas Andersen and Shaun McCance (Yelp).


=
Officially announce libglade as deprecated in favor of GtkBuilder
=
NOT COMPLETED - To be discussed at the upcoming release-team meeting.


=
Clear a11y plan and schedule for 3.0
=
NOT COMPLETED, but on a good way.
See http://live.gnome.org/Accessibility/BonoboDeprecation and
http://mark.doffman.com/index.php/2009/04/29/accessibility-30/ .

WillieWalker working on it.


=
Less than 18 modules depending on libgnome
=
NOT COMPLETED:
low: 17
average: 4 (Evolution, gnome-media, yelp, anjuta)
complex: 1 (gok)

Please share experiences and knowledge at
http://live.gnome.org/LibgnomeMustDie .


=
Less than 18 modules depending on libgnomeui
=
COMPLETED:
low: 12
average: 2 (Evolution-Exchange, gnome-panel)
complex: 1 (Evolution) 

Please share experiences and knowledge at
http://live.gnome.org/LibgnomeMustDie .


=
ZERO modules dependening on Esound
=
COMPLETED.
Thanks to Gerd Kohlberger (GOK).


=
ZERO modules dependening on Gnomeprint
=
COMPLETED.
Thanks to Thomas Andersen (gnome-games).


=
ZERO modules dependening on gnome-vfs
=
COMPLETED.
Thanks to Simon van der Linden, Willie Walker, Carlos Eduardo Rodrigues
Diógenes (gnome-mag).


=
Less than 25 modules with Gtk-Deprecated-Symbols, 
less than 6 modules with complex status, 
less than 6 modules with average status
=
NOT COMPLETED, but still very good progress:
low: 6
average: 7 (gnome-control-center, evolution, gedit, librsvg, metacity,
glade)
complex: 3 (gnome-games, gnome-media, libglade*)


=
Evolution-Data-Server must be migrated to d-bus by default
=
NOT COMPLETED, but on its way.
Git branch at
http://git.gnome.org/cgit/evolution-data-server/log/?h=dbus

chen asked ross about eds-port and the reply was ideally it would be
done for 2.27.2 :) so not sure
robster i just refreshed and tidied up the addressbook port
* robster has a contacts working against current dbus port.


=
gtkhtml must not depend on Bonobo anymore
=
COMPLETED.
Thanks to Matthew Barnes.


=
GNOME-SHELL alpha release
=
NOT COMPLETED.
owen we took a big step towards packageability by switching over to
mutter. Though really, I'm not sure how much time I want to spend
rolling tarballs that are going to quickly go out of date


=
WebKit status report for 2.27.5
=
WebKitGTK+ has been proposed as an external dependency.
See the thread
http://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00010.html


=
Evolution to get rid of Bonobo by 2.27.3
=
mbarnes I still have a lot of work to do on the calendar.  haven't
lost hope for 2.27.3 but the the deadline's approaching fast
See http://www.go-evolution.org/KillBonobo .
Git branch at http://git.gnome.org/cgit/evolution/log/?h=kill-bonobo


=
Complete migration from HAL to 

Platform

[Shaun McCance]

Hey folks,

I'm taking a hard look at the Platform Overview and how we
can improve our message to ISDs through better documentation.
Our release sets, unfortunately, don't really reflect what we
really recommend to developers.  That role has more or less
been delegated to the Platform Overview.

The problem is that what's in the Platform Overview is based
entirely on what I happened to think was worth mentioning at
some point.  I should not be the arbiter of our platform.

I would like to get people's opinions on what technologies
we should be pushing.  I'm interested both in the here and
now and in what people think the Gnome 3 message should be.

I've organized my thoughts into three categories: Platform
contains technologies that are currently in our Developer
Platform release; Recommended contains thing that we seem
to agree we should push, but are either in the Desktop
release or just in our external dependencies; and Others
contains stuff that I think is cool and could be part of
our core offering some time in the indeterminate future.

The list is what came to mind as I was writing this email.
Please feel free to discuss libraries I forgot.


Platform


GTK+ -- The core of how we make graphical applications.

Pango -- Internationalized text rendering system.  You
love it and you know it.

GLib -- The foundation for pretty much everything we do.

GIO -- Part of GLib, but worth a separate mention in the
Platform Overview.

GConf -- Configuration system.  There is talk of a new
system (see below).  But I think it's obvious that we need
to be pushing something here.  So as long as GConf is what
we have, it's what we push.

ATK -- Accessibility toolkit.  Used by GTK+.  Should be
used by anything else that does UIs.


Recommended
===

Cairo -- Incredible drawing library, used by GTK+.  There
seems to be general agreement that developers should use
Cairo when they need to do custom drawing.

GStreamer -- All things multimedia.  I don't think there's
any argument against GStreamer being the Gnome-blessed way
to do multimedia.

D-Bus -- Inter-process messaging system.  Lots of stuff is
built on it.  How much do we want to push it directly?

Avahi -- Service discovery.  This is used in quite a few
places.  I know some people in the past had talked about
having a simple wrapper in GLib.  How much do we push it?

gnome-keyring -- Storing passwords and other secrets.  I
think this is an important thing to offer ISDs, but this
seems to be languishing as a desktop-only thing.

evolution-data-server -- Address book and calendaring.
I've seen half a dozen projects come and go that aim to
augment or replace e-d-s.  We seem to like the idea, but
I'm not sure we all love the implementation.

libsoup -- HTTP library.  Honestly, HTTP is such a core
thing these days, we need to offer something.  Everybody
seems generally happy with libsoup in general.  Should it
be in the Platform?  Should its functionality just live
in GLib alongside fancy new networking stuff?

libxml2/libxslt -- We put these into the external deps
a couple release cycles back.  Do we want to continue
pushing them as part of our platform?


Others
==

GSettings -- GConf replacement to live in GLib.

Telepathy -- Instant messaging and beyond.  I think
there is a lot of really cool potential here.

Libchamplain -- Wicked cool mapping library.  This is
not something I would have thought of as something we
need to offer.  But now that it's here, it's a really
compelling technology with a lot of potential.

Clutter -- Are we actively embracing Clutter, or is it
just something we're OK with people using?  The message
is unclear.

Tracker -- I don't think we can afford to be without a
search system.  This isn't just about having file search
as a feature.  It's about providing something that ISDs
can leverage to make their applications better.

GNIO -- Networking library for GLib.

WebKit -- More and more applications are finding uses
for an embedded HTML rendering widget.  I think we need
to provide one with a solid API.  WebKit seems to be the
direction people are heading in.

Various D-Bus services and APIs -- DeviceKit, PolicyKit,
ConsoleKit, I think there's something for power management,
etc.  Are these things we expect applications developers
to use directly?  What's our message?


All right, that's what's come to mind so far.  I'd also
like to discuss what we're pushing on the mobile front,
but that's another can of worms.

I'm really curious to hear what the community thinks.

Thanks,
Shaun


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

Re: Platform

[Shaun McCance]

On Tue, 2009-05-05 at 14:05 -0500, Shaun McCance wrote:
 Hey folks,
 
 I'm taking a hard look at the Platform Overview

http://library.gnome.org/devel/platform-overview/stable/index.html

For those who don't know.

--
Shaun


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

Re: Platform

[Matteo Settenvini]

Il giorno mar, 05/05/2009 alle 14.05 -0500, Shaun McCance ha scritto:
 Hey folks,

[...]

 
 The list is what came to mind as I was writing this email.
 Please feel free to discuss libraries I forgot.
 

Thanks Shaun, you're wonderful as always. I also think it would be nice
to mention gobject-introspection in a separate part, because using it we
can easily provide bindings to other languages and many other nifty
things.

As for other things: is GNOME pushing tracker, beagle or just xesam (now
that it's published)? Maybe I'm a bit confused about all this. Please
help me understand.

seed may be worth mentioning. Also libcanberra.

Another question: what about inserting a section about gtk-doc and/or
doxygen? Documenting source code is quite important.

Thanks,
Matteo



signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Shaun McCance]

On Tue, 2009-05-05 at 21:25 +0200, Matteo Settenvini wrote:
 Il giorno mar, 05/05/2009 alle 14.05 -0500, Shaun McCance ha scritto:
  Hey folks,
 
 [...]
 
  
  The list is what came to mind as I was writing this email.
  Please feel free to discuss libraries I forgot.
  
 
 Thanks Shaun, you're wonderful as always.

Aw shucks. :)

  I also think it would be nice
 to mention gobject-introspection in a separate part, because using it we
 can easily provide bindings to other languages and many other nifty
 things.

There's a section on bindings.  I'd like to put more
in there, but I'd need some help.  Perhaps it could
be discussed in the lead-in?

 As for other things: is GNOME pushing tracker, beagle or just xesam (now
 that it's published)? Maybe I'm a bit confused about all this. Please
 help me understand.

I am too.  Throw Nepomuk into the list of things to
be confused about.

 seed may be worth mentioning. Also libcanberra.

I did think about Seed.  And there's GJS.  I'm not
entirely sure how we imagine this fitting in.  Is
it just another binding, or is it something we want
to push as a framework to be used no matter what
core language your application is written in?

Good catch on libcanberra.  It's clearly good for us
to have a convenient API for this.  Do we really want
to push another micro-library for that?  Should GTK+
just learn to do it?

 Another question: what about inserting a section about gtk-doc and/or
 doxygen? Documenting source code is quite important.

I've thought about doing a section on development
tools in general.  This would fit nicely there.

--
Shaun


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

Re: Platform

[Brian Cameron]

Shaun:

Shouldn't GStreamer be included for media support?  If not
in the Platform, then at least Recommended?

Also, what about gvfs, libdaemon, and libunique?

Brian


On 05/05/09 14:05, Shaun McCance wrote:

Hey folks,

I'm taking a hard look at the Platform Overview and how we
can improve our message to ISDs through better documentation.
Our release sets, unfortunately, don't really reflect what we
really recommend to developers.  That role has more or less
been delegated to the Platform Overview.

The problem is that what's in the Platform Overview is based
entirely on what I happened to think was worth mentioning at
some point.  I should not be the arbiter of our platform.

I would like to get people's opinions on what technologies
we should be pushing.  I'm interested both in the here and
now and in what people think the Gnome 3 message should be.

I've organized my thoughts into three categories: Platform
contains technologies that are currently in our Developer
Platform release; Recommended contains thing that we seem
to agree we should push, but are either in the Desktop
release or just in our external dependencies; and Others
contains stuff that I think is cool and could be part of
our core offering some time in the indeterminate future.

The list is what came to mind as I was writing this email.
Please feel free to discuss libraries I forgot.


Platform


GTK+ -- The core of how we make graphical applications.

Pango -- Internationalized text rendering system.  You
love it and you know it.

GLib -- The foundation for pretty much everything we do.

GIO -- Part of GLib, but worth a separate mention in the
Platform Overview.

GConf -- Configuration system.  There is talk of a new
system (see below).  But I think it's obvious that we need
to be pushing something here.  So as long as GConf is what
we have, it's what we push.

ATK -- Accessibility toolkit.  Used by GTK+.  Should be
used by anything else that does UIs.


Recommended
===

Cairo -- Incredible drawing library, used by GTK+.  There
seems to be general agreement that developers should use
Cairo when they need to do custom drawing.

GStreamer -- All things multimedia.  I don't think there's
any argument against GStreamer being the Gnome-blessed way
to do multimedia.

D-Bus -- Inter-process messaging system.  Lots of stuff is
built on it.  How much do we want to push it directly?

Avahi -- Service discovery.  This is used in quite a few
places.  I know some people in the past had talked about
having a simple wrapper in GLib.  How much do we push it?

gnome-keyring -- Storing passwords and other secrets.  I
think this is an important thing to offer ISDs, but this
seems to be languishing as a desktop-only thing.

evolution-data-server -- Address book and calendaring.
I've seen half a dozen projects come and go that aim to
augment or replace e-d-s.  We seem to like the idea, but
I'm not sure we all love the implementation.

libsoup -- HTTP library.  Honestly, HTTP is such a core
thing these days, we need to offer something.  Everybody
seems generally happy with libsoup in general.  Should it
be in the Platform?  Should its functionality just live
in GLib alongside fancy new networking stuff?

libxml2/libxslt -- We put these into the external deps
a couple release cycles back.  Do we want to continue
pushing them as part of our platform?


Others
==

GSettings -- GConf replacement to live in GLib.

Telepathy -- Instant messaging and beyond.  I think
there is a lot of really cool potential here.

Libchamplain -- Wicked cool mapping library.  This is
not something I would have thought of as something we
need to offer.  But now that it's here, it's a really
compelling technology with a lot of potential.

Clutter -- Are we actively embracing Clutter, or is it
just something we're OK with people using?  The message
is unclear.

Tracker -- I don't think we can afford to be without a
search system.  This isn't just about having file search
as a feature.  It's about providing something that ISDs
can leverage to make their applications better.

GNIO -- Networking library for GLib.

WebKit -- More and more applications are finding uses
for an embedded HTML rendering widget.  I think we need
to provide one with a solid API.  WebKit seems to be the
direction people are heading in.

Various D-Bus services and APIs -- DeviceKit, PolicyKit,
ConsoleKit, I think there's something for power management,
etc.  Are these things we expect applications developers
to use directly?  What's our message?


All right, that's what's come to mind so far.  I'd also
like to discuss what we're pushing on the mobile front,
but that's another can of worms.

I'm really curious to hear what the community thinks.

Thanks,
Shaun


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


___
desktop-devel

Re: Platform

[Matteo Settenvini]

Il giorno mar, 05/05/2009 alle 14.41 -0500, Brian Cameron ha scritto:
 Shaun:
 
 Shouldn't GStreamer be included for media support?

It's in the list (second item of the Recommended section) :-)

 
 Also, what about gvfs, libdaemon, and libunique?

gvfs could be introduced along with GIO; as for libunique, I gather that
plans were there to put that functionality inside Gtk+. Any update on
that?

I don't know about libdaemon.

 
 Brian

Matteo


signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Paolo Borelli]

Hi Shaun

Il giorno mar, 05/05/2009 alle 14.05 -0500, Shaun McCance ha scritto:

 Recommended
 ===
 
 Cairo -- Incredible drawing library, used by GTK+.  There
 seems to be general agreement that developers should use
 Cairo when they need to do custom drawing.
 

I do not think that putting cairo (and to some lesser extent d-bus and
libxml) in the same bucket of gstreamer or e-d-s is an accurate
representation to communicate to ISDs: cairo is used by any app which is
using gtk and offers (at least afaik) the same api and abi guarantees.
It just happens to be an external dependency because its developement
extends beyond gnome and its schedule.

I feel it should be mentioned in a separate section (Foundations?) along
with xorg, xlib, fontconfig, pixman and maybe even d-bus and libxml

Ciao
Paolo

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

Re: Platform

[Tristan Van Berkom]

On Tue, May 5, 2009 at 3:05 PM, Shaun McCance sha...@gnome.org wrote:
 Hey folks,
[...]
 I would like to get people's opinions on what technologies
 we should be pushing.  I'm interested both in the here and
 now and in what people think the Gnome 3 message should be.


Hi,
   Great time to brain-storm what we have...

I think we should put some emphasis on the devtools suite in
general, a basic we have tools message is called for.

Personally, I always compile gnome relocated by hand, I tried
jhbuild years ago and found it clunky then, Im trying MacPorts
now and find it works awesome, where are we with jhbuild ?
theres also another one out there iirc, cant remember the name...

I would be interested to know, what do we all generally recommend
in terms of a tool/setup to compile gnome ?

... anyway, that should also be part of this message, we have tools
and we can make it easy for you to build...

[...]

 GConf -- Configuration system.  There is talk of a new
 system (see below).  But I think it's obvious that we need
 to be pushing something here.  So as long as GConf is what
 we have, it's what we push.

ditto GConf as dbus below, settings, setting observations and
messaging to into a need-to-have bundle IMO

[...]
 D-Bus -- Inter-process messaging system.  Lots of stuff is
 built on it.  How much do we want to push it directly?

I think we want to push this alot, applications need IPCs,
I would expect a book about developing with GNOME
technologies to include a chapter on IPC/settings and
an observer model (something like GConf I guess, we
have GConf over dbus ? or GSettings now ? sorry for
not knowing all the details ...).

From what I gather... which is a little vague... using some
language bindings you can observe the state of an object
even if its in another process, GObject mapping over dbus
is something I heard of... does that really exist ? if so,
its something people need to hear about..

Anyway IMO we need to have an IPC to use in the platform.

[...]

 libxml2/libxslt -- We put these into the external deps
 a couple release cycles back.  Do we want to continue
 pushing them as part of our platform?


I think its important to have an xml library, what is here
to replace libxml2 ? (maybe I'm missing something...)


[...]

 Libchamplain -- Wicked cool mapping library.  This is
 not something I would have thought of as something we
 need to offer.  But now that it's here, it's a really
 compelling technology with a lot of potential.

+1 for the ooh-aah factor heh

 Clutter -- Are we actively embracing Clutter, or is it
 just something we're OK with people using?  The message
 is unclear.

I am privately embracing Clutter myself, I think its wrong
to consider it as a drop in replacement for GTK+,
right now I would probably recommend Clutter or another
leading canvas like hippo-canvas, to do anything really
fancy in a UI...

 WebKit -- More and more applications are finding uses
 for an embedded HTML rendering widget.  I think we need
 to provide one with a solid API.  WebKit seems to be the
 direction people are heading in.

just pointing out that the next generation mozilla (xulrunner)
will also sport a portable embeddable GTK+ widget... although I
dont really have an opinion about what we should push in
this regard...


Anyway I should get back to work... thanks for starting this
thread, Im also interested to hear what people have to say ;-)

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

Re: Platform

[Shaun McCance]

On Tue, 2009-05-05 at 21:59 +0200, Paolo Borelli wrote:
 Hi Shaun
 
 Il giorno mar, 05/05/2009 alle 14.05 -0500, Shaun McCance ha scritto:
 
  Recommended
  ===
  
  Cairo -- Incredible drawing library, used by GTK+.  There
  seems to be general agreement that developers should use
  Cairo when they need to do custom drawing.
  
 
 I do not think that putting cairo (and to some lesser extent d-bus and
 libxml) in the same bucket of gstreamer or e-d-s is an accurate
 representation to communicate to ISDs: cairo is used by any app which is
 using gtk and offers (at least afaik) the same api and abi guarantees.
 It just happens to be an external dependency because its developement
 extends beyond gnome and its schedule.

Sorry, I should have been more clear.  The sections
in this email were just for this email.  I didn't
intend for them to reflect sections in the Overview
itself.

 I feel it should be mentioned in a separate section (Foundations?) along
 with xorg, xlib, fontconfig, pixman and maybe even d-bus and libxml

That's the kind of input I'm looking for.  There are
numerous technologies that we build on but don't push.
So, for instance, X is certainly at the core of of all
our graphical technologies, but it's almost completely
hidden from an API perspective.  We don't spend a lot
of documentation effort telling people about all the
cool things they can do with X.

So do we treat Cairo as an implementation detail, or
is it something we talk up?  My thoughts are that if
you're doing anything non-trivial, you're probably
going to need to do some custom drawing outside of
what GTK+ provides.  Cairo is extremely cool, and I
think we should communicate that.

--
Shaun


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

Re: Platform

[Shaun McCance]

On Tue, 2009-05-05 at 14:41 -0500, Brian Cameron wrote:
 Shaun:
 
 Shouldn't GStreamer be included for media support?  If not
 in the Platform, then at least Recommended?

It's in there.

 Also, what about gvfs, libdaemon, and libunique?

GVFS doesn't provide API.  On the other hand, it
does make GIO much more awesome.  It's currently
discussed in the section on GIO, and I don't have
any plans to change that.

Shouldn't libunique be a part of GLib?

What's libdaemon?

--
Shaun


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

Re: Platform

[Behdad Esfahbod]

On 05/05/2009 04:20 PM, Shaun McCance wrote:


So do we treat Cairo as an implementation detail, or
is it something we talk up?  My thoughts are that if
you're doing anything non-trivial, you're probably
going to need to do some custom drawing outside of
what GTK+ provides.  Cairo is extremely cool, and I
think we should communicate that.


We really want to advertise it as part of developing with GTK+.  It's your 
one-stop shop for all drawing (*and* printing).  So, it's a great relief that 
it's a separate component, but one that we need to extensively invest on.


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

Re: Platform

[Lennart Poettering]

On Tue, 05.05.09 16:33, Matthias Clasen (matthias.cla...@gmail.com) wrote:

  What's libdaemon?
 
 libdaemon is an implementation detail of pulseaudio as far as I am concerned.

Just for correctness' sake: it's an implementation detail of Avahi,
not of PulseAudio.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Marc-André Lureau]

Hi

On Tue, May 5, 2009 at 11:33 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:

 libdaemon is an implementation detail of pulseaudio as far as I am concerned.


PulseAudio does not use libdaemon, afaik. Avahi, maybe?

regards,

-- 
Marc-André Lureau
Sent from Helsinki, Southern Finland, Finland
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform

[Matthias Clasen]

On Tue, May 5, 2009 at 4:22 PM, Shaun McCance sha...@gnome.org wrote:

 Also, what about gvfs, libdaemon, and libunique?

 GVFS doesn't provide API.  On the other hand, it
 does make GIO much more awesome.  It's currently
 discussed in the section on GIO, and I don't have
 any plans to change that.

 Shouldn't libunique be a part of GLib?

Unique application and session support should be moving into GTK+, eventually.
For that to happen, we need to sort out dbus support in glib first.
See current gtk-devel-list discussions, and
http://bugzilla.gnome.org/show_bug.cgi?id=579571

 What's libdaemon?

libdaemon is an implementation detail of pulseaudio as far as I am concerned.


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

Re: Platform

[Rodrigo Moya]

On Tue, 2009-05-05 at 14:36 -0500, Shaun McCance wrote:
 
 Good catch on libcanberra.  It's clearly good for us
 to have a convenient API for this.  Do we really want
 to push another micro-library for that?  Should GTK+
 just learn to do it?
 
yeah, in fact, libcanberra provides a libcanberra-gtk lib which could be
part of GTK. libcanberra itself, I guess, would need to keep as a
separate lib for KDE and others to use it (if they do or plan to, which
I'm not sure about)
-- 
Rodrigo Moya rodr...@gnome-db.org

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

Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Stefan Kost]

Andre Klapper schrieb:
 Ahoj,

 a draft for the GNOME 2.27  2.29 schedule is now available at

 http://live.gnome.org/TwoPointTwentyseven .

 The schedule also includes a plan to clean up the platform by getting
 rid of deprecated modules.
 Maintainers can see the GNOME 3 readiness of their modules on Frederic's
 awesome status page at http://www.gnome.org/~fpeters/299.html .
 Comments  discussion welcome.
   
I woner what we will do with gnome-canvas? I don't think we should
deprecate it without an official alternative and some migration
support/guide.

Stefan
 Notes:
   * 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general
 GNOME 3 debate, please see other threads like Vincent's recent
 posting at
 
 http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg4.html 
 and 
 http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg5.html ). 
 I don't plan to cover everything+1 in this schedule, it's just that I 
 concentrated on platform streamlining.)
   * Only two maintenance releases for 2.28.x
   * Early module freeze for 2.30
   * More  earlier 2.29.x releases than normally (better testing)
   * Two weeks hardcode freeze before 2.30.0 - late release at the
 last day of march 2010
   * Still to discuss: dconf vs gconf. This is not yet covered by
 this plan, but crucial to discuss (as gconf depends on Bonobo) -
 robtaylor and/or desrt will probably elaborate its current
 state.
   * Still to discuss: a11y plan for GNOME3 - see
 http://live.gnome.org/Accessibility/BonoboDeprecation


 Already know some 2.28 plans for the module you maintain?
 Add them to http://live.gnome.org/RoadMap now!

 andre
   

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

Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Jean Bréfort]

Le lundi 06 avril 2009 à 17:10 +0300, Stefan Kost a écrit :
 Andre Klapper schrieb:
  Ahoj,
 
  a draft for the GNOME 2.27  2.29 schedule is now available at
 
  http://live.gnome.org/TwoPointTwentyseven .
 
  The schedule also includes a plan to clean up the platform by getting
  rid of deprecated modules.
  Maintainers can see the GNOME 3 readiness of their modules on Frederic's
  awesome status page at http://www.gnome.org/~fpeters/299.html .
  Comments  discussion welcome.

 I woner what we will do with gnome-canvas? I don't think we should
 deprecate it without an official alternative and some migration
 support/guide.

If nothing uses it anymore in the official gnome modules (btw, did
something used it?), deprecate it. It is almost unmaintained, AFAIK. Of
course, there is no official alternatives, but I don't think there will
be one in a foreseeable future. Just defining what it should do will be
quite difficult since there seems to be so many divergent opinions among
the community. And even if somebody is able to write a multipurpose
canvas, it might not fulfill everybody's needs. For my use case, I
tested libccc and goocanvas, and in the end it took me less time to
write a new widget from scratch with all the features I need and just
these.

Best regards,
Jean

 Stefan
  Notes:
* 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general
  GNOME 3 debate, please see other threads like Vincent's recent
  posting at
  
  http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg4.html 
  and 
  http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg5.html 
  ). I don't plan to cover everything+1 in this schedule, it's just that I 
  concentrated on platform streamlining.)
* Only two maintenance releases for 2.28.x
* Early module freeze for 2.30
* More  earlier 2.29.x releases than normally (better testing)
* Two weeks hardcode freeze before 2.30.0 - late release at the
  last day of march 2010
* Still to discuss: dconf vs gconf. This is not yet covered by
  this plan, but crucial to discuss (as gconf depends on Bonobo) -
  robtaylor and/or desrt will probably elaborate its current
  state.
* Still to discuss: a11y plan for GNOME3 - see
  http://live.gnome.org/Accessibility/BonoboDeprecation
 
 
  Already know some 2.28 plans for the module you maintain?
  Add them to http://live.gnome.org/RoadMap now!
 
  andre

 
 ___
 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: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Vincent Untz]

Le jeudi 02 avril 2009, à 11:26 -0400, Willie Walker a écrit :
 2) We are working with another organization right now to investigate  
 magnification solutions.  This may involve picking up on  
 http://projects.gnome.org/outreach/a11y/tasks/magnification/, and I  
 suspect the ultimate solution will be a combination of improvements to  
 Compiz's eZoom plugin plus a D-Bus API.  If so, this may end up as a  
 Compiz project.

I guess we'd probably want to have GNOME Shell people involved there,
since this would be something that would need to be implemented there
too...

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Havoc Pennington]

Hi,

On Thu, Apr 2, 2009 at 9:51 AM, Cosimo Cecchi cosi...@gnome.org wrote:
 I add another question here, as a complete dconf/GConf newbie:
 is depending on Bonobo/Corba vs DBus the only thing that makes GConf not
 useful towards GNOME 3.0 or are there some other
 design/preformance/whatever issues requiring a full rewrite to be
 solved?

http://projects.gnome.org/gconf/plans.html
http://projects.gnome.org/gconf/plans-spec.html

(would recommend checklisting dconf against this list, I think Ryan
and I did a couple years ago, but there's been a lot of change since)

 We learned, with the GIO transition, that porting lots of applications
 isn't fun, and is something which takes much time to be completed
 project-wide. As GConf is probably even more widely used than gnome-vfs
 was, porting could be an even bigger effort.

The only sane thing imo would be to have a gconf compatibility wrapper
around dconf.

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

Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Josselin Mouette]

Le vendredi 03 avril 2009 à 09:48 -0400, Havoc Pennington a écrit :
  We learned, with the GIO transition, that porting lots of applications
  isn't fun, and is something which takes much time to be completed
  project-wide. As GConf is probably even more widely used than gnome-vfs
  was, porting could be an even bigger effort.
 
 The only sane thing imo would be to have a gconf compatibility wrapper
 around dconf.

AOL. The timeframe looks way too short to allow for completing dconf and
porting all applications before the 3.0 release.

-- 
 .''`.  Debian 5.0 Lenny has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Andre Klapper]

Ahoj,

a draft for the GNOME 2.27  2.29 schedule is now available at

http://live.gnome.org/TwoPointTwentyseven .

The schedule also includes a plan to clean up the platform by getting
rid of deprecated modules.
Maintainers can see the GNOME 3 readiness of their modules on Frederic's
awesome status page at http://www.gnome.org/~fpeters/299.html .
Comments  discussion welcome.

Notes:
  * 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general
GNOME 3 debate, please see other threads like Vincent's recent
posting at

http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg4.html and 
http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg5.html ). I 
don't plan to cover everything+1 in this schedule, it's just that I 
concentrated on platform streamlining.)
  * Only two maintenance releases for 2.28.x
  * Early module freeze for 2.30
  * More  earlier 2.29.x releases than normally (better testing)
  * Two weeks hardcode freeze before 2.30.0 - late release at the
last day of march 2010
  * Still to discuss: dconf vs gconf. This is not yet covered by
this plan, but crucial to discuss (as gconf depends on Bonobo) -
robtaylor and/or desrt will probably elaborate its current
state.
  * Still to discuss: a11y plan for GNOME3 - see
http://live.gnome.org/Accessibility/BonoboDeprecation


Already know some 2.28 plans for the module you maintain?
Add them to http://live.gnome.org/RoadMap now!

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

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

Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Alberto Ruiz]

2009/4/2 Andre Klapper ak...@gmx.net:
 Ahoj,

 a draft for the GNOME 2.27  2.29 schedule is now available at

        http://live.gnome.org/TwoPointTwentyseven .

 The schedule also includes a plan to clean up the platform by getting
 rid of deprecated modules.
 Maintainers can see the GNOME 3 readiness of their modules on Frederic's
 awesome status page at http://www.gnome.org/~fpeters/299.html .
 Comments  discussion welcome.

 Notes:
      * 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general
        GNOME 3 debate, please see other threads like Vincent's recent
        posting at
        
 http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg4.html 
 and 
 http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg5.html ). 
 I don't plan to cover everything+1 in this schedule, it's just that I 
 concentrated on platform streamlining.)
      * Only two maintenance releases for 2.28.x
      * Early module freeze for 2.30
      * More  earlier 2.29.x releases than normally (better testing)
      * Two weeks hardcode freeze before 2.30.0 - late release at the
        last day of march 2010
      * Still to discuss: dconf vs gconf. This is not yet covered by
        this plan, but crucial to discuss (as gconf depends on Bonobo) -
        robtaylor and/or desrt will probably elaborate its current
        state.
      * Still to discuss: a11y plan for GNOME3 - see
        http://live.gnome.org/Accessibility/BonoboDeprecation

How does the release of Gtk+ 3.0 fits with this schedule. Is this
something totally independent?

 Already know some 2.28 plans for the module you maintain?
 Add them to http://live.gnome.org/RoadMap now!

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

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




-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Ross Burton]

On Thu, 2009-04-02 at 13:20 +0200, Andre Klapper wrote:
   * Still to discuss: dconf vs gconf. This is not yet covered by
 this plan, but crucial to discuss (as gconf depends on
 Bonobo) 

There is gconf-dbus, the long-standing port of GConf to DBus that
Imendio did for Maemo.  Moblin also ships it and it shouldn't be *too*
difficult to merge it back[1].

Ross

[1] I may regret saying this
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Alberto Ruiz]

2009/4/2 Ross Burton r...@burtonini.com:
 On Thu, 2009-04-02 at 13:20 +0200, Andre Klapper wrote:
       * Still to discuss: dconf vs gconf. This is not yet covered by
         this plan, but crucial to discuss (as gconf depends on
 Bonobo)

 There is gconf-dbus, the long-standing port of GConf to DBus that
 Imendio did for Maemo.  Moblin also ships it and it shouldn't be *too*
 difficult to merge it back[1].

My understanding on this after talking with Richard Hult, is that
there is no GConf maintainer, and the DBus port is a huge hack and not
really suitable for the main branch, and that a proper merge would
need a lot of work.

 Ross

 [1] I may regret saying this
 --
 Ross Burton                                 mail: r...@burtonini.com
                                          jabber: r...@burtonini.com
                                           www: http://burtonini.com

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




-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Ross Burton]

On Thu, 2009-04-02 at 13:41 +0100, Alberto Ruiz wrote:
 My understanding on this after talking with Richard Hult, is that
 there is no GConf maintainer, and the DBus port is a huge hack and not
 really suitable for the main branch, and that a proper merge would
 need a lot of work.

There being no GConf maintainer makes this easy for a suitably willing
person to do the merge.  I prefer the phrasing needs cleaning up to a
huge hack myself though. :)

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Alberto Ruiz]

2009/4/2 Ross Burton r...@burtonini.com:
 On Thu, 2009-04-02 at 13:41 +0100, Alberto Ruiz wrote:
 My understanding on this after talking with Richard Hult, is that
 there is no GConf maintainer, and the DBus port is a huge hack and not
 really suitable for the main branch, and that a proper merge would
 need a lot of work.

 There being no GConf maintainer makes this easy for a suitably willing
 person to do the merge.  I prefer the phrasing needs cleaning up to a
 huge hack myself though. :)

Well, at this point we have someone willing to write a piece of
software with loads of benefits and some code available over GConf and
none volunteering on doing the merge. Unless you are volunteering
yourself :-)

 Ross
 --
 Ross Burton                                 mail: r...@burtonini.com
                                          jabber: r...@burtonini.com
                                           www: http://burtonini.com




-- 
Un saludo,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list