This discussion is helpful. Would you add or modify the following feedback
through error code proposal?
Paul
A. Initialization
B. Closure
C. Directory
D. Read
E. Write
--------------
A. Configuration problems should a be separate errorspace (at the time of
initialization):
0. Success
1. invalid command line options
2. no 1-wire source (bus master) specified
3. no 1-wire source (bus master) available
4. insufficient permission from operating system
99. Unknown error
B. Closing should be a separate errorspace
0. Success
99. Unknown error
(D) Read and (C)Directory should be a combined errorspace (because "get" can
be either) and we might as well combine (E)Write since there is considerable
overlap:
0. Success
1. Uninitialized
2. Directory (not appropriate)
3. Not a directory (not appropriate)
4. Read not supported
5. Write not supported
6. Read-only
7. Invalid path
8. Invalid device (CRC wrong)
9. Invalid device (alias error?)
10. Bus does not exist
11. Bus is not working
12 Bus is wrong type
13 Bus short
14. Not an array
15. Array out of bounds
16. Not a scalar
17. Not a bitfield
18. 1-wire error
99. Unknown error
On Fri, Aug 19, 2011 at 1:27 PM, Mark Richards
<mark.richa...@massmicro.com>wrote:
> On 8/19/2011 12:43, ekgnkb3d wrote:
>
> Paul Alfille-2 wrote:
>
> Do you have an idea of what information you want from the error code?
>
>
> I would like to distinguish between errors in:
> - The application: like a typo in the path which is is nonsens (e.g.
> "uncaxxched/", or "temperature21" in a DS18B20)
> - The configuration: like accessing a invalid device (e.g. CRC is not valid,
> wrong format "/28.7A00.0E" or "/28.7X20Z&010000.0E"
> - The hardware: like non reachable devices (e.g. devices never been
> connected, temporarily unavailable, shorted bus)
>
> My 0,002 c, which may help the discussion, maybe..
>
> 1. It seems to me that "application errors" would be confined to:
> - bad path (device path not present or typo error)
> - bad configuration information (ow_init)
> - invalid request (asking the API to do something that cannot be done)
>
> 2. Configuration errors would fall within (1) as they relate to ow_init.
>
> Both 1 and 2 seem to be already covered in the API.
>
> New items (?):
>
> 3. Bus or device errors
> - CRC fail on read/write/scan/convert, etc
> - Bus short
> - Adapter connected but not responding
> * owfs presumably knows when an adapter has connected and somehow
> determines that it has disconnected.
> It may be impossible to distinguish a disconnected adapter from
> an adapter that is connected but unresponsive.
> This is particularly true with the DS2490 which locks up during
> a bus short condition and can only be recovered by
> cycling power to the DS2490 (and bus, if a powered bus).
>
> 4. Bus events (not errors)
> - Adapter connected/removed
> - Device connected/removed
>
> Bus or Device Errors:
> * expose a single global bit state indicating:
> - an error on a device
> - an error on a bus
> - an adapter error
> * elaborate on error within the end-structure of the specific owfs
> device, in the case of a device error, or the root in the case of an
> adapter.
> ./CRC_error (retry count)
> ./error_desc (string)
>
>
> In the case of a missing device (where your application has stored the
> address, the device is taken off the bus, and your application does not know
> this fact) OWFS will also return EINVALID. I am not certain that it's
> possible to distinguish the difference. However, it would be nice to have
> an event fired (or queued and available by interrogation via the API) when a
> device is added or removed. This would allow the user application to
> remain in sync. In my case I will just re-scan the entire owfs network
> anyway, so a single event saying "changed" is sufficient.
>
> /m
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
