[plt-scheme] re: question about symbol data type implementation in mzscheme

From: Richard Cleis (rcleis at mac.com)
Date: Sun Nov 21 11:47:37 EST 2004

I don't think I can make a wise response without knowing more about 
your protocols.  It still seems that a schemeplementation could reduce, 
as devices are discovered, suites of functions and parameters into a 
smaller set of functions, with very few parameters, that are needed for 
that device.

rac


On Nov 21, 2004, at 7:40 AM, Matt Dawson wrote:
>
> This is good "pushback". The problem comes from my own delusions of
> granduer. Instead of developing a protocol very specific to one devie
> I'm trying to develop an generic protocol that could work with many
> different types of devices -- something that could become and open
> standard.
>
> Here is a little more detail to explain why I think that there will 
> have
> to be a proliferation of symbols.
>
> Industrial automation protocols are usually broken down into two parts.
> There is the "application layer" and the "device profile".  The
> application layer provides generic infrastructure for communicating 
> with
> a device but is not specific to any particular device class. The
> application layer could work equally well for a refrigerator or a
> digital servo drive. The device profile is a set of rules/conventions
> for talking to a particular class of device. My company has a number of
> products that use a protocol called CANOpen. The CANOpen application
> layer views devices as "things with setup parameters". Each setup
> parameter has an a numeric address. The "device profile" for a device
> like a digital servo drives specifies what the actual setup parameters
> are and what there addresses are. For instance it might specify that
> parameter 7 is the set speed for the motor.
>
> In my scheme inspired protocol symbols like "new", "send", and "define"
> are part of the application layer. My application layer models all
> devices as "things with objects". There are a generic set of mechanisms
> for invoking methods and creating new objects. The device profile for a
> particular class of device specifies what the actual objects and 
> classes
> are. The device profile for a device like a refrigerator might define a
> "refrigerator%" class and an "ice-maker%" class. To determine whether
> the ice-maker was working correctly you would send an expression like
>
>    (send (send device get-ice-maker) operating-normally? )
>
> Here the root device is an instance of a "refrigerator%". The
> "get-ice-maker" method returns a reference to an "ice-maker%" object.
> The "ice-maker%" class has a method called "operating-normally?".
>
> Symbols like "get-ice-maker" and "operating-normally?" are part of the
> refrigerator device profile. Each profile will require its own set of
> symbols. A symbol like "operating-normally?" might get used in serval
> different device profiles.
>



Posted on the users mailing list.