As an avid photographer (diglloyd.com), I'll weigh in here--
1. Unless Sun provides frequent and regular updates automatically to
support the latest digital cameras, including 'dcraw' in Solaris is
likely to disappoint--new cameras are released on a constant basis,
and a RAW-file converter must be constantly updated to keep pace.
IMO, 'dcraw' seems inappapriate for Solaris, unless there is a plan
in place to keep pace on the latest cameras.
By way of comparison, Apple provides RAW support in Aperture, Preview
and internal libraries, and they have to issue an update once a
quarter or so. Right now, I have a new camera, and it's not yet
supported (though it soon should be). This becomes annoying; any
tool that isn't aggressively updated gets abandoned.
In short, failure to aggressively update raw-file processing software
frequently leads to it being out of date within a year. To me,
that's *much* more important than concerns about whether the
interface is 'volatile' or something else--a square peg in a round
hole issue IMO.
Bottom line: unless we have a team committed to frequent and regular
updates, I vote against seeing this included in Solaris *at all*.
I could be persuaded otherwise provided that there is a *funded* and
well-articulated plan for aggressively keeping 'dcraw' current.
Lloyd
Lloyd L Chambers
lloyd.chambers at sun.com
LSARC
Sun Microsystems, Inc
On Jan 30, 2008, at 5:34 AM, James Carlson wrote:
> John Plocher writes:
>> Danek Duvall wrote:
>>> Perhaps we could keep track of these interfaces...
>>
>> If you are going to do all that, why not just do a contract - it is
>> just as much work, plus it is a well known mechanism.
>>
>> (I, too wish there was a better way...)
>
> I agree with John. I'll also go further to say that asserting that
> because a project exports only Volatile interfaces it's somehow
> specially eligible to import Volatile as well is a syntax error. It
> seems to belie a "FOSS == no review" scheme that just doesn't exist.
>
> We don't evaluate dependencies based on the stability of interfaces
> provided by a project. We evaluate them based on the consolidations
> across which the dependency exists.
>
> In other words, better ways to deal with this issue are:
>
> - Just raise the stability level of the library to an appropriate
> level, given the consumers involved. It's not as unstable as
> asserted.
>
> - Create a contract; it's how we enumerate consumers who will be
> damaged by unexpected changes.
>
> - Put them in the same consolidation and treat the dependency as
> effectively Consolidation Private ("Volatile friends with
> benefits").
>
> --
> James Carlson, Solaris Networking
> <james.d.carlson at sun.com>
> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442
> 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442
> 1677
---
Lloyd L Chambers
lloyd.chambers at sun.com
Sun Microsystems, Inc
