[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix-xml] Things I'd like to discuss at tomorrow's telecon.
I hope you can all easily read my comments below, in blue.
Sam
> -----Original Message-----
> From: Aaron Hansen [mailto:ahansen@tridium.com]
> Sent:
Tuesday, February 22, 2005 6:54 PM
> To: Sam Yang
> Cc:
obix-xml@lists.oasis-open.org
> Subject: Re: [obix-xml] Things I'd like to
discuss at
> tomorrow's telecon.
>
>
> Sorry I wasn't
clear, I meant the root object of the read or write
> operation, not the
entire tree.
>
> I'm not against paths, but I think they might be an
unnecessary
> complication. The need is for every object to have a
unique
> identifier,
> but I don't see any need for that identifier
to be a path.
> If we don't
> need to get into the issue of
path seperator and escape character,
> wouldn't we be better
off?
Without pathing, how does a client efficiently
access a particular node anywhere in the hierarchy? Using a path as the id
value, you can get the exact object you want with a single depth-0 Read, giving
a time complexity of O(1). Without pathing, it seems to me the client must
first discover the node (even though the client already knows the logical path
to it), performing D-1 Reads (with a depth of 1, where D is the depth of the
node), resulting in a complexity of O(D*N), where N is the average number of
child nodes.
>
> I don't feel that strongly about
handles, and I also get the feeling
> there could be something down the
road that I'm not seeing which
> benefits from pathing. Can anyone
think of what that might be to cut
> short this discussion at the
meeting?
What is the difference between a "handle"
and an opaque id?
>
>
> As for depth, think about
this:
>
> 1. Read object1, depth 1:
>
<object1>
> <object 1
metadata>
>
<children>
> <object
2>
>
<object2
meta-data
>
<more children>
>
> 2. Read object2, depth 1:
>
<object 2>
> <object 2
metadata>
>
<children>
>
...
>
> See, object 2 was completely re-read. It is impossible
to
> traverse the
> tree without completely re-reading entire
objects. I think
> most people
> will want to traverse oBIX
trees using a depth of one, in which case
> they will read twice as much
information than they need. It just
> doesn't seem right to
me.
>
In step 1, you could just ask for a
minimal amount of data for object1's child nodes (maybe just their ids) and
nothing else. There is no need to get everything twice. I can see,
though, that just getting (opaque) child ids is not generally useful, because
you'd usually want to know additional information about a child (like, its real
non-opaque identity) before using the child node. Therefore, you can't
usually avoid getting some data twice. This is another excellent argument
for pathing.
> See you all at the meeting.
>
>
Thanks,
> Aaron
>
>
> Sam Yang wrote:
>
>
> > -----Original Message-----
> > > From: Aaron Hansen [mailto:ahansen@tridium.com]
> >
> Sent: Tuesday, February 22, 2005 7:46 AM
> > > To:
obix-xml@lists.oasis-open.org
> > > Subject: [obix-xml] Things I'd
like to discuss at tomorrow's
> > > telecon.
> >
>
> > >
> > > Pathing
> > >
========
> > > - Isn't the need only to identify the root object for
read/write
> > > operations? If so,
> > > - I don't
think there is a need for pathing
> > > - I'm leaning towards an
opague "handle" which is the unique
> > > identifier.
>
>
> > I don't understand this point. Since the oBIX design
assumes that
> > every oBIX server exposes a node hierarchy of
arbitrary
> depth, I don't
> > see how you can avoid supporting
the addressing of every
> node in the
> > hierarchy (whether that
addressing is opaque or not).
> Maybe by "root"
> > you
mean something other than the "root object", as used in
> the
draft
> > spec?
> >
> > Also, assuming that we will
support addressing arbitrary nodes, how
> > can a client efficiently
read the state of a node that is, say, 15
> > levels below the root
node? In the current draft spec, it
> seems that
> > the
client would have to to perform 14 Read operations (each
> > specifying
a depth of 1) and look at some sort of identifying
> > information in
all the objects returned with each Read
> response to see
> >
which one is on the "path" to the desired node (or is the node
> >
itself). (The client could instead make one call with a
> depth of
14,
> > but that could result in an outlandishly large
response).
> Since the
> > IDs used for all nodes are
"opaque" (as a consequence of which the
> > client has no idea how
permanent the ID/node mapping is),
> the client
> > should not
even persist what it has learned about the hierarchy for
> > use in a
future session (on the other hand oBIX has no concept of a
> > client
"session", so maybe opaque IDs have to have
> permanent mappings
>
> to nodes?).
> >
> > An easier approach would be to use a
path that is composed
> of a string
> > of IDs (maybe the same as
the identifiers contained in the
> objects for
> > each node
along the path) separated from each other by a simple
> >
delimiter. The state of the desired node can be obtained with a
>
> single Read request, and a developer/debugger might even be able to
>
> look at the requests and responses and figure out what
> nodes are
being
> > referenced.
> >
> > >
> >
>
> > > Misc notes
> > > =========
> > >
- Should ObjectReadType be ObjectType?
> > > - Need default values
for:
> > > * DimensionType ->
everything
> > > * FacetsType ->
resolution, precision, writable
> > > *
AlarmType -> inAlarm
> > > * ReadReqType
-> locale, depth
> > > - How about ext element in IncludeType be
a boolean?
> Think it would
> > > be much
easier.
> > > - Shouldn't facets have trueText and
falseText?
> > > - Units: I still don't like unit refs.
> >
> * We don't have unit read operation.
> >
> * Which object holds the master unit? What if
the
> client hasn't
> > > read it yet?
> >
> * Id should be a unique unit identifier, the client
can
> > > table on that.
> > > - What is root?
>
>
> > The root could just be a special container for the real
nodes
> > (like the DOM Document Node is a container for the
Document
> Element).
> > The root node is already defined
to have an empty ID, so it
> is already
> > not like a "real"
node.
> >
> > > - If read depth is 0, should more children
be indicated?
> >
> > As I recall, we decided "yes".
>
>
> > > - How about an object version? If used, this could
be used to
> > > indicate an object's facets have changed.
>
> >
> > > I don't like depth
> > >
=============
> > > - We'll end up double reading most objects
during discovery
> > > (especially if everyone uses depth 1 as I
feel they will). Think
> > > about it.
> > > - In
my tests, a depth a 5 resulted in a massively large
>
document.
> > > This feature is dangerous.
> > > -
I think read should simply list children handles.
> >
>
> I don't think we should eliminate depth and simply
> enumerate all
child
> > IDs -- that would make Reads too verbose in a lot of
cases. I had
> > brought up the "dangerousnous" of large depth
before, but I though
> > there was a feeling among the other members
that "we are
> dealing with
> > enterprise servers and clients,
and they can handle
> anything". That's
> > why we didn't
provide a way to get a child count, as I had
> wanted. I
>
> think that we should leave depth the way it is (or at most
> limit
its
> > value range to [0..1]).
> >
> > >
>
> > Thanks,
> > > Aaron
> > >
> >
>
> > >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]