Browse Implementation --------------------- 1. OPC XML-DA is very flexible in defining requirements for server paths and items design. As unique item indentifier is used conncotenated ItemName and ItemPath values. There are both of them can be constructed from any printable Unicode characters. For browsing pruposes uses some tree structure (not depended at all on this ItemPath) any opc item can be "directory", "item" or both of them. For implementation diecided to use most common unix directory structure ( including soft links). Only exclusion: any "item" may be as well "directory" and vice versa. By design this should be used to provide additional information about HDR items (like data description). Such combined item can be freeily destroyed from creator plugin. In case it still needed as "directory" only "item" part will be really destroyed. Directory will be destroyed automatically later when it will go out of neccesarity. Still it isn't very difficult to reimplement this in other way. Most method depended code is in: opctree.c opcitem.c opcserver.c/RegisterItem() 2. Because of "Browse" is long procedure and can be done in several client requests it's unclear when apply filters. Information can be changed during interval between client requests. Following approach now is used: Apply all filters on first request. On effective requests of items only presistance will be checked. All information about item properties will be requested only on client's effective request. another approach would be: To get on first request only list of items. But all filters also apply on effective request. It's hard to say wich way is correct. Second one will give a bit more contemporary information, still first one more traditional and requires less computational power. Still because of modular organization it's only several lines of code to change between this implementations. Most method depended code is in: opcitem.c/opcItemBrowse opcserver.c/???