Re: [Libphidget-devel] Documentation?

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

According to Jack Strohm:

> On Fri, 2002-09-06 at 21:37, Vadim Tkachenko wrote:
> > Jack Strohm wrote:

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

"shouldn't" and "wouldn't" are different things ;) As a paranoid type, I'd
go as far as checking the heap (if it is accessible, of course) for the
pointers to those phidget_type objects... I need to get my memories about
C/C++ back, then I'd be able to give an educated guess on how to do it.

> > Let me play a devil's advocate for a while...
> 
> uh-oh, let me get my crosses and holy water  ;-)

Get some more ;)

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

OK, good, now we're getting some use cases for the phidgets.

1. read
2. write
3. upload firmware
4. receive arrival notification
5. receive departure notification
6. receive property change notification (?)

What else?

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

Funny question: is it possible to have a device driver that is running 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!)
 
An example I forgot about when I was writing the previous message:

/dev/phidget/servo
                  /controller/<id>
                                  /propeties
                                  /servo/<id>
                                             /properties
                                             /stream
                                  

Something like that.

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

If I guessed it right, then

/dev/phidget/rfid/<id>
                      /properties
                      /stream

> The Phidget manager is a "singleton" object, there is one, and can only
> be one created, if you access it, it is created automatically.

Damn, C++ guys have it easy - in Java, there's always a possibility to end
up with multiple "singletons" if you start fiddling with class loaders, and
there's always a possibility that you're not the only who tries to
instantiate the same singleton, often with different parameters -
singletones and Java just don't mix...

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

Well, probably, but the phidgets are more than just toys - they're real
world devices, and it's quite possible that some people (count me in) will
try to treat them as grown-up things ;)

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

I'm with you here... Almost ended up rewriting the USB subset for Java, and
the only thing that prevented me from doing it was lack of time and the fact
that I've finished scratching my itch.

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

Maybe it is so in C++ world. However, speaking for myself, I've spent last 7
years in Java and got eventually fed up with it for one simple reason: it's
BIG. OK, you can put together something in a day that you'd spend a month
doing in C++ (collections, threading, etc.), fine, but the weight of the
resulting code is just overwhelming.

Now, I feel that I'm not the only one... And people who turn back to C++
from Java *are* spoiled - all in all, it's a beautiful environment. I want
my threads. I want my semaphores. I want my <name it>.

And the real world applications of phidgets will most probably be MT.

OK, done ranting.

> I do want to make it MT safe so
> that it won't prohibit you from using it in MT applications.

Cool ;)

--vt