I think points 1. and 2. are related. I think any node in a path should be
able to represent the id of a point, and that therefore a point should be
able to contain other points. We should be as generic as possible, and not
prevent that.
-----Original Message-----
From: Aaron Hansen [mailto:]
Sent: Thursday, January 06, 2005 7:27 AM
To: Obix-Xml-Sc (E-mail)
Subject: [obix-xml] Issues
Well I've finally started implementing. I haven't gotten very far, but here
are some shiny issues that caught my eye.
1. Containers vs. Objects
- We don't distinguish between containers and objects. Currently it is
possible for a point to contain a point. Is this common? I'd rather see
the burden be on the vendor who has to decompose such constructs.
2. Pathing again
- After mentioning a commands service, I started thinking (for once)... We
would have to develop a whole new model for complex arguments. However, if
an object's id is it's leaf name then we could use the existing object
schema and even incorporate commands into Sys. So I now support pathing and
changing read/write/subscribe to using paths instead of id's.
3. Polling
- Since we can't add/remove points from a subscription, the likely
implementation scenario will be a subscription for every container. This
could lead to a client with many threads polling a server. I would like to
see the pollReq allow multiple subscription id's.
