Should have been more specific. I wasn't actually thinking
so much about the implementations as profile structure that
is defined here:
http://www.w3.org/TR/CCPP-struct-vocab/#CCPPProfileStructOverview
j.
Curt Sampson wrote:
> On Tue, 26 Feb 2002, Jon Ellis wrote:
>
>
>>http://www.ccpp.org/ might be worth looking at...
>>
>
> I just downloaded it and checked it out. A few random comments.
>
> 1. These guys really don't believe in documentation (beyond "see
> the website", which says only "coming soon").
>
> 2. They use XML files to describe the capabilities of the devicesk,
> which is good.
>
> 3. The guy just *loves* String objects. Not only does he create
> (possibly large) Strings when he should just be passing around a
> Reader-type object (a common mistake in Java that destroys
> performance), but at one point, he passes a list of items by
> constructing a String containing comma-separated names, which he
> then parses! I guess he figured that if it worked in perl....
>
> 4. It doesn't feel terribly object oriented. When you start making
> classes with static methods, and passing objects into these methods
> to get information out of them, you can smell that something's not
> quite right there. I think in part this is because it's based on
> DELI, which also does not feel terribly OO. (Things like returning
> a String when you get a resolution rule--how on earth do you parse
> it and use it?)
>
> 5. It's based on DELI, for which you can get more info here:
>
> http://www.hpl.hp.com/techreports/2001/HPL2001-260.html
> http://www-uk.hpl.hp.com/people/marbut/deli/
>
> DELI, which I also downloaded and looked at, seems from the paper
> in the first link above to be a lot more complexity than the problem
> really justifies. Do we really need a huge pile of default resolution
> rules to determine whether or not a device has sound? It seems to
> me to be easier just to say "yes," "no," or "the profile didn't
> say." And that avoids getting a default value from somewhere that
> is in fact incorrect; I should think most applications would rather
> know that they don't know than use a wrong value.
>
> I also sense a sort of basic problem in DELI: it's supposed to let
> devices tell you about their capabilities, so you can change things
> to suit them. But one of the main reasons you want to set up a
> device database like this is due to bugs in devices; they don't do
> what they're supposed to. That probably means they also don't do
> what the profile says. Now DELI does seem to offer the ability to
> override some of the information you get from the device by
> downloading, say, an bug report from the manufacturer's web site,
> but the complexity here is starting to get quite disturbing.
>
> cjs
>
Received on Tue Feb 26 16:09:30 2002