From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <e505ef2007299b298f253cf2a65b9aff@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel
From: Charles Forsyth <forsyth@terzarima.net>
In-Reply-To: <200403010934.i219YNhh064852@adat.davidashen.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Mon,  1 Mar 2004 10:40:16 +0000
Topicbox-Message-UUID: 069c15a4-eacd-11e9-9e20-41e7f4b1d025

my point was just that programmers, presumably `average' ones as well,
often need to come to grips with a fair number of non-trivial things,
and they are often rather specific (as with the JMF).  it seems to me that
if programmers can deal with things such as those (not just those particular things),
there's a reasonable chance that at least a good percentage can indeed deal with
something that is more fundamental, and more general.
of course part of what is discovered, taught and learnt,
is what discipline to follow to avoid trouble (as in structured programming),
and even when concurrency is best avoided.   of course talents will vary, but
even so.

>>remembering all the details
>>of Java Media Framework is no more necessary than remembering all

i chose it as an example of a moderately complex interface only
because i was on the JMF email list years ago and still
retain the following e-mail message from that list, as an example of
how one can produce fairly intricate interfaces (that did get in the way).
my favourite part is the last paragraph, which reminds me of the sketch
in the Life of Brian: ``the people's liberation army of judea'', 
``the judean people's liberation army'', ... .  splitters!


	Subject: DataSource and Player coupling
		...

	I'm writing a java.media.content.reliable.DataSource implementation for
	use with Intels Java Media implementation. I'm not sure how to get the
	framework to use my DataSource without resorting to writing my own
	Player implementation (or instantiating an undocumented internal Player
	implementation)

	I could use a unique protocol (e.g. softcom:) and implement a
	java.media.protocol.softcom.PlayerFinder which somehow determines the
	MIME type and then calls
	java.media.content.reliable.<mime-type>.PlayerFinder.createPlayer()
	passing an instance of my DataSource implementation. Or I could create
	an instance of my DataSource and create an instance of the correct
	content PlayerFinder directly, e.g.:

	 DataSource ds = new MyDataSource(url);
	 java.media.content.reliable.PlayerFactory pf =
	                new
	java.media.content.reliable.video.mpeg.PlayerFinder();
	 m_jmPlayer = pf.createPlayer(ds);

	I would still need to determine the MIME type of the source URL in order
	to locate the PlayerFinder.

		...

	DataSource and Player implementations seem tightly bound together in the
	framework.  I would think they should be independent so I can mix and
	match DataSources with Player implementations.

	Also, it seems strange that the DataSource is in a content specific
	package, e.g. java.media.content.reliable.<mime-type>.DataSource. The
	DataSource doesn't need to know anything about the content - it just
	reads raw bytes - why does it care if they are MPEG, AVI, WAV etc.?  It
	would seem more sensible to tie the DataSource to the protocol, e.g.
	java.media.protocol.<protocol>.DataSource.

	In fact, why are the reliable and streaming packages tied to content
	type (java.media.content.reliable and java.media.content.streaming)?
	It's the protocol that is reliable or streaming, not the content (is
	MPEG reliable or streaming? it depends on the protocol). Shouldn't these
	packages be named java.media.protocol.reliable and
	java.media.protocol.streaming?