My monthly 'oh yeah, the platform' mail

--===============1896480647==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-UTm2491HcJ0R2l7Quww2"


--=-UTm2491HcJ0R2l7Quww2
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Sigh ... don't mistake the self-referential humour for any sign that I
don't take this sort of thing seriously.  And apologies for the breaking
of threading here -- since fooishbar.org was compromised with fd.o, I've
had to shift all my mail over to an Evolution setup on my laptop, and
haven't got it playing nicely with my old mail yet.  But anyway, I
digress.

So, in my previous effort to do stuff[0], I drew the battle lines, as it
were, thusly: ICCCM vs. technology pimping, and what we need to do.  I
stated that I was on the side of technology pimping: we can use the
platform as a mechanism to make the world aware of really cool
technology like D-BUS, HAL, Cairo, whatever, and push it out that way.
On the other hand, we could do a small, stable, release of a bunch of
specifications: 'a waste'.

I made my argument for a technology platform in the last two mails --
essentially, we could craft a platform with which to show ISVs what we
could really do.  System-wide yet desktop-integrated IPC,
backend-independent vector graphics, Just Working hardware, oh my!

Unfortunately this didn't generate enough (read: any) discussion, but it
did at least generate some thoughts on my end.  So, have the 'case for
ICCCM' mail.

freedesktop.org is, essentially, a technology organisation.  A group of
hackers and a community, but the end results of this are very visible --
talented guys producing projects like D-BUS, HAL, Cairo, and many other
incredibly worthy projects which fall under the fd.o umbrella.  As such,
just having a project hosted on fd.o (and thusly
http://projectname.freedesktop.org) is 'technology pimping' in and of
itself.  The association with fd.o already implicitly does this.
Through all the X development in particular, fd.o is rather synonymous
with 'cool new technology'.

On the other hand, freedesktop.org dates back to 1999, according to the
domain info, and has historically -- and currently -- had another very
important role in the specification of standards to be used by common
implementations.  A quick look over shows a raft of incredibly useful
standards which have been quite crucial to gaining a coherent desktop.
So, obviously there must be a great deal of importance placed on
standards.

The LSB are already around to provide a stable, known API/ABI platform
for ISVs; so, accordingly, anything we do must be viewed as intruding on
their turf.  Not as a bad thing -- no more than us providing hosting for
desktop projects and thus intruding on SourceForge's turf is bad -- but
something to be considered nonetheless.

It's occurred to me that we're looking at two completely different
things:
  * platform
  * stack

There is a call for a 'freedesktop.org platform' which includes our
core: things like desktop-entry-spec, menu-entry-spec.  The sort of
things my current system would fall apart without.  I believe this sort
of thing needs to be *defined*, because hell, that's what standards are
-- nothing if not defined.

I think this is where our platform should go.

But I can't trivialise the 'stack' at the same time: X.  We wouldn't
have a desktop without it.  My desktop, via some fantastic creep, is
becoming massively reliant on D-BUS, and things like HAL.  I sense it
will become rather reliant on Cairo in the near future.

But these don't need to be defined; no more than we need to define, say,
the Xrandr API as a formal standard.  We have defined the X protocol,
and if we want to make standards that *use* these elements of the stack,
that's fantastic.  If you want to make a standard that involves D-BUS --
and you have everyone using D-BUS -- go nuts.  That would be fantastic.
But I don't see a role for D-BUS as a standard in and of itself.

So, I (re)propose a freedesktop.org platform that includes
interoperability standards and specifications.  And not software.  The
current obvious standards are:
  * desktop-entry-spec
  * menu-spec
  * wm-spec

... and whatever else people can think of.  I'm not a desktop developer,
so people who actually develop this stuff on a daily basis -- let us
know.

Comments from Mike Hearn, Chris Lee, Havoc Pennington and George Kraft
specifically would be welcome, as they were heavily involved in the
original discussions; but please, all comments welcome.

Finally, I would like to apologise for the job being done so far from my
end; I realise it sucks.  July 31st was a long, long time ago; I've been
drowning in lots of work since, and the platform wasn't exactly
low-hanging fruit.  Volunteers welcome.

Daniel

[0]:
http://lists.freedesktop.org/pipermail/platform/2004-November/000112.html

--=-UTm2491HcJ0R2l7Quww2
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBv0V6RkzMgPKxYGwRAiDKAJ4qZYzC1RSyU/xqJ2RiMv47lP6GGACfauqQ
qX6Oj9zNkNmVK/tVNYWntJE=
=rOdD
-----END PGP SIGNATURE-----

--=-UTm2491HcJ0R2l7Quww2--

--===============1896480647==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
platform mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/platform

--===============1896480647==--