Am 25.11.2015 um 10:03 schrieb Stefano Miccoli:
> Cannot check right now, but if I didn’t do something terribly wrong I
> should be at the latest commit on master, so below e85572.
>
> It seems to me that actually e85572 introduced the bug:
>
> http://sourceforge.net/p/owfs/code/ci/e855721f4e02fd93b5345ba8e89462043973ba28/tree/module/owlib/src/c/ow_read.c?diff=706f0c578a6f77daf9fb3dca0af7fd608d5e0ca4
>
> In fact you cannot read a directory, so at the very beginning of
> FS_read_postparse you should have at least
>
> // ServerRead jumps in here, perhaps with non-file entry if
> (pn->selected_filetype == NO_FILETYPE) { return -EISDIR; }
>
That's exactly the problem I was addressing with that commit. When you
do it that simple way, there is *no way* you can export external sensors
via owserver to owlib based clients. Which makes it kind of pointless to
have this feature at all.
owlib based clients rely on knowing the filetype of nodes inside device
directories in advance. The can do that because they know the structure
of the chip directories. It's a whitebox.
ownet based clients instead first do a owdir on each node, if that fails
they do owread. Remote structure is a blackbox. (The owread and owdir
programs of course not, they just fail if the filetype is wrong.)
But for external sensors (and the MOAT, too), owlib has to step away
from the whitebox system and do it the ownet way, too. Because remote
clients haven't got the external structure file loaded and so, they
don't know whether to owdir or owread on a node in advance.
Sure, we could implement a structure distribution mechanism, but the
blackbox support has still to coexist just because abadoning it would
break nearly all language bindings and existing programs.
I will check your example and try to get this working with the blackbox
mechanism.
> Expected behaviour is that reading a directory should return error 21
> (EISDIR), and this should happen early, not after trying to read the
> bus.,
>
The big problem is you don't know in advance whether it's a directory if
the node is on a owserver using and external sensors structure file.
>
> In owserver instead, ow_get returns either the content of a file or
> the listing of a directory, which indeed is a terrible idea, since
> the client has no way to know what it is returned (a value or a
> listing.). I understand that ow_get cannot be scrapped right now, but
> it should at least be deprecated.
>
Well, please suggest a mechanism which does not break existing ownet
language bindings. Or you have to clean up the mess all on your own.
Kind regards
Jan
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
