Hi, first thanks for answering.

> I can't imagine what sending I2C to a socket would be like, but that's
> interesting.
I think I'd encapsulate the orders in strings (I could use XML tags an copy RPC,
for instance). The server would then just decapsulate them with a XML parser.

> > My teachers would like me
> > to make my class as a stream : I2CStream. Currently I don't really think
> > I'm fluent enough with the notion of stream, but I can still read any API's
> > documentation on my own.
>
> But I2C typically is message oriented, not stream oriented (that is, it's
> more
> or less a datagram protocol). Each message has an address, a read/write bit,
> and optional data. I'm not sure that it would make sense to make it into a
> stream.
>
> Or maybe you could layer a stream on top of the I2C messages (but then you'd
> need to encapsulate a stream protocol in I2C).


> Further, there isn't a clean model for bidirectional streams
> (command/response) in Squeak.
Are you allunding to the fact that a stream is not meant to be used for a
dialog-based communication but rather to handle messages coming at
unpredictable moments? If so, as you say, I may need another model : I2C is
designed to always have an answer for one given request.

> In my experience with I2C [1], I've found that the need to define a protocol
> that defines a message structure precludes making a general I2C stream
> interface.


> I don't know what kind of device you're talking to, but does it really
> understand a stream protocol?
My device is a kind of robot made out of two commands modules transmitting data
between the motors/captors/LED and the software. It comes from our students and
it could understant what we want him to.

> Typical in my experience is this kind of protocol is something like the SMBus
> protocol (see http://www.charmed.com/txt/smbus-protocol.txt), which defines a
> number of different read/write message formats that are defined by the
> receiving devices themselves.


> I'd probably use a SharedQueue (which is sort of like a double-ended stream)
> to connect to an I2C handler; its contents would be transaction-level objects
> which would then be converted into a series of I2C messages.
Do you mean I should send high-level data through the SharedQueue and let the
receiver decode this data afterwards (for example, the abstract command
"go-forward" would trigger a I2C sequence with START, ADDRESS RESOLUTION, ACK,
DATA, STOP).


Thank you very much for your guidance.