Re: [Libphidget-devel] Documentation?

[Jack S. <js...@ja...>]

On Fri, 2002-09-06 at 21:37, Vadim Tkachenko wrote:
> 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?

Can't occur.

> - Is the library thread safe?

Not yet.  I have thought about it.

> - What happens if wrong arguments are supplied (suppose, someone
> deallocated the phidget_type and forgot to discard the reference, and
> called a function again)?

since users don't allocate phidget_type they shouldn't ever deallocate
them.  

> 
> 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?
> 

I think so.  But generic to USB is generic to phidget.


> Let me play a devil's advocate for a while...

uh-oh, let me get my crosses and holy water  ;-)

>  
> > 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.

I was looking at it from another point of view.  I own phidgets, I want
to interact with them.  I don't care that they are USB, I want to know
when they attach/detach, I want there firmware to be uploaded, and I
want to be able have a simple way to access all of there accessories. 
This was never meant to be generic beyond phidgets.

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

Why is that?  I actually started playing with kernel drivers, but I kept
getting everyone telling me to stay in user space.

> 
> 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...

that is what I'd like to implement.  Although I don't have any input
devices to play with. (please Chester send me some!)

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

I've been looking at the VB api to figure out the capabilities of the
devices (although I'm not copying that API)

> >         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.

No you don't ever need to know the manager exists.  Currently the way
the C++ code works, you can do this 

main()
{
	CServo servo(CUID(741,0))

	servo.position(.5);
}

no manager needed, the manager it dynamically created the first time it
is needed.  Now if you wanted the Phidget Servo controller you can do
this:

main()
{
	CServoController controller(CUID(741));

	CServo *servo=controller.servo(0,true);

	servo->position(.5);
}

This does the same thing, with a bit more control, now we have access to
the servo controller. (actually this is bugged, but it will work soon).

The Phidget manager is a "singleton" object, there is one, and can only
be one created, if you access it, it is created automatically.  So, as a
user if you want it you can get it:

	CPhidgetManager *manager=CPhidgetManager::getInstance();

but if you don't want it, you don't even need to know it exists.

> 
> 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...

Well this project is just for interacting with phidgets.  So that's why
it's just phidgets and not all USB devices.  There are other USB drivers
for other devices.  I wanted to abstract away the entire USB API so the
user wasn't exposed to it (cause it can get a little weird).

> 
> 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?

Me and a friend thought about this a lot, and we decided just polling
for events would be easier to implement and get the job done just as
well.  Most applications aren't MT.  I do want to make it MT safe so
that it won't prohibit you from using it in MT applications.