Re: [Libphidget-devel] Documentation?

[Vadim T. <vt...@fr...>]

Jack Strohm wrote:
> 
> On Fri, 2002-09-06 at 03:30, Vadim Tkachenko wrote:

> > - What integrity enforcement measures were embedded into the implementation?
> 
> Could you explain what you mean by this in more details.

- Is it possible to accidentally create more than one master list of
phidgets?
- Is the library thread safe?
- What happens if wrong arguments are supplied (suppose, someone
deallocated the phidget_type and forgot to discard the reference, and
called a function again)?

This is easier done in C++ than in C, granted...

> > - (since I haven't seen the device docs yet) What are the features common to
> >   all the Phidgets? Being pessimistic, so far I haven't seen any. Therefore,
> >   a question - how justified is the PhidgetManager?
> 
> As for common features among all phidgets, all that I am aware of is the
> ability to get the device's serial number.

But isn't this a generic USB feature?

Let me play a devil's advocate for a while...
 
> PhidgetManager's main reason for existence:
> 
>         1) it knows about all phidget devices on the system.  The user can
> query for the existence of certain types of phidgets or for a specific
> phidget and the manager handles this query.

Suppose I'm the user. Do I really care if it is a Phidget? Not really...
To me, this is a USB device that just happens to be a Phidget, that's
all. What I care about, instead, is that when this USB device arrives,
its capabilities are accessible, and it would be a good thing if the
arrival is announced. Possibly together with some device initialization,
and possibly I'd like to have some persistent properties of this device
restored.

All abovesaid somehow makes me think about the kernel drivers, though
;)))

Give you an example: if I have an LCD phidget, I'd probably like to
treat it as a stream device supporting ANSI escapes so I can position
the text and/or set the colors, if it is color... If it is an RFID (let
me speculate that RFID is a chip that can be "scanned", exactly as the
items are scanned on a checkout line in the store), then I'd probably
like to have the device that will just send me arrival notifications
from the RFID chips...

(granted, the RFID example was farfetched, I have no idea how it works)

>         2) Dynamically allocates phidgets objects that the user doesn't want to
> allocate himself, but may still need.  For example a user can create a
> servo object that allows him to access a specific servo, but doesn't
> have to create the phidget object manually.  The servo object is created
> (either with new or on the stack).

Again, do I need to even know about the phidget manager in order to
create a servo instance? I may need to be aware of the abstraction of
the servo controller in case the servo controller, as an entity, offers
some configuration, but to the best of my recollection at least the
QuadServo is able to control the individual servo's properties, and the
servo controller doesn't have any tuneups. So, in this case, I'd rather
create the servo instance directly (based on the controller serial # and
servo #) and work with it.

But, if you talk about introspection, then the picture changes... I'd
rather be able to walk the device tree and find all the abstractions,
but again, does it have to be a Phidget or a generic USB device? Open to
speculation...

Another thing I don't know how to approach - in Java, one is spoiled
with listeners and asynchronous notifications. In C++, this will involve
multithreading context, which I'm not ready to take on 'cause last time
I've touched it was in OS/2 in 1994... Can you shed some light on this,
please?

--vt