Andy, Giovanni,
First, excellent conversation – so good
that I’ll schedule it as an agenda item for tomorrow’s telecon (I’ll put it at
the start so Giovanni doesn’t have to stay up late).
FWIW, here’s my perspective: I like the
way Giovanni described a use case like notifications as “a well
defined pattern of interactions between the XDI server and the client”. I think
that anything that fits this description is a candidate to be part of the
protocol – specifically, part of the XDI Dictionary of $words that are
machine-understandable semantics used to control data flow (notifications being
one form of data flow). Link contract negotiation is another example of such
well-defined patterns of interaction.
So even though the actual notification mechanism may be
implementation-specific, the ability to subscribe to a notification, update
that subscription, or delete that subscription may fall within our work.
I look forward to more discussion tomorrow (sending the agenda
next).
=Drummond
From:
andy.dale@ootao.com [mailto:andy.dale@ootao.com]
Sent: Wednesday, May 02, 2007 8:18
AM
To: Giovanni Bartolomeo
Cc: blefari@uniroma2.it; Drummond
Reed; stefano salsano; steven.churchill@ootao.com; xdi@lists.oasis-open.org;
xri@lists.oasis-open.org
Subject: RE: [xdi] notifications
for XDI? (was Re: prototype and consequent feedback on XDI primitive)
I'm still not sure if I fully understand the use
case... but I think I do. If I do then this answer should make sense....
There
are existing client platforms that have notification mechanisms specified. All
we need to do is build plugins that adhere to those specs that are triggered at
the appropriate times.
It
is a good question as to how much we include in the specs. ooTao is building a
series of indexing plugins based on a indexing scheme that we have devised.
This scheme makes it easy to 'search' for authorities with specific
characteristics (get +email where +city ='Oakland'). This seems to be a vital
part of any useful deployment (at least in all of the use cases we have been
addressing) but I'm not sure I would include it in the core XDI spec set. It is
'one-way' of using the xdi primitives to achieve the desired goal but surely
not the only way and once we all get smarter about xdi we may well find that
it's not the best way. The same way as full-text-indexing is a pluggable
component in RDBMS I think that both the indexing and notifications should
stand separate.
That
doesn't mean we shouldn't spec the hell out of our implementations and publish
them. Depending on the licensing you want to use we can include all these
components as either part of core distribution or as add-ons... but either way,
my gut says... specify plugin triggering as part of the core xdi spec... let
plugins develop out of the community enabling maximum innovation.
With
that said, I would be happy to work closely with you to specify the
notification plugin. Steve Churchill is also an expert on pub/sub models and
can bring his expertise to the table.
Meanwhile...
rather than talking about talking about it... I'd be happy to jump into the
technical meat of the conversation. Ultimately I don't care if the notification
mechanism is part of the core spec or not. I do understand the need for the
functionality and would love to be part of us getting it as good as we can at
this stage. So... we could schedule a call with a webEx session or you
can just send me a first pass doc to start the exchange.
What
do you think?
Andy
Dale
ooTao, Inc.
Phone: 877-213-7935
Fax: 877-213-7935
i-name: =Andy.Dale
http://xri.net/=andy.dale
***************************************************************************
If you don't have an i-name yet use this link to visit one of our partners and
buy one:
http://www.ezibroker.net/partners.html
***************************************************************************
Giovanni Bartolomeo
<giovanni.bartolomeo@uniroma2.it>
05/02/2007 07:37 AM
|
To
|
andy.dale@ootao.com, "Drummond
Reed" <drummond.reed@cordance.net>
|
cc
|
steven.churchill@ootao.com,
xdi@lists.oasis-open.org, xri@lists.oasis-open.org, blefari@uniroma2.it,
stefano salsano <stefano.salsano@uniroma2.it>
|
Subject
|
RE: [xdi] notifications for XDI? (was Re:
prototype and consequent feedback on XDI primitive)
|
|
Dear Drummond and Andy,
thanks for your replies. It seems that you both got perfectly the point!
And that we agree that this mechanism is useful and perhaps a request for
specifications may fit (e.g. describe the subscription/notification mechanism,
interface, error/fault messages, etc. - so called "abstract
protocol", regardless it will be implemented using RSS or others - we
offer to do this).
If I've understood correct, basically Andy says: we can leave notification as a
"standard" plugin for XDI servers. I'm wondering if this
"standard" plugins are reflected "officially" in the XDI
specs or are let to any implementation. I think it depends on how
"standard" they'll be :-)
However, my idea is that if we recognize a well defined pattern of interactions
between the XDI server and the client, as this seems the case, we should write
something about it to provide guidelines for implementation... Andy, what's
your opinion about it?
Thanks in advance,
Giovanni
At 16.54 30/04/2007, andy.dale@ootao.com wrote:
I think we DO need to
specify a robust 'trigger' mechanism (which we have done in our
implementation). These triggers can trigger the execution of any custom code,
on either get or set traversals. They can be triggered at any specific point in
the get or the set operations (before set, after set, etc...). To build a
plugin that implements the notification protocol you describe is then trivial,
as is building any other protocol or domain specific functionality. We
are building several 'standard' plugins that will be part of every server
distribution, a notification one could be added to the set.
With such a generic solution I don't see why the XDI TC would want to take on
the additional work of tightly binding itself to any other specific spec or
protocol.
All the best,
Andy Dale
ooTao, Inc.
Phone: 877-213-7935
Fax: 877-213-7935
i-name: =Andy.Dale
http://xri.net/=andy.dale
***************************************************************************
If you don't have an i-name yet use this link to visit one of our partners and
buy one:
http://www.ezibroker.net/partners.html
***************************************************************************
"Drummond Reed" <drummond.reed@cordance.net>
04/29/2007 09:23 PM
To
"'Giovanni
Bartolomeo'" <giovanni.bartolomeo@uniroma2.it>,
<xri@lists.oasis-open.org>, <xdi@lists.oasis-open.org>
cc
<steven.churchill@ootao.com>,
<andy.dale@ootao.com>
Subject
RE: [xdi]
notifications for XDI? (was Re: prototype and consequent feedback on XDI
primitive)
Giovanni,
I apologize for the long delay in replying – I was at the OASIS Symposium the
week before last and am still catching up on lists.
See [=Drummond] inline.
From: Giovanni Bartolomeo [
mailto:giovanni.bartolomeo@uniroma2.it]
Sent: Friday, April 13, 2007 9:26 AM
To: xri@lists.oasis-open.org; xdi@lists.oasis-open.org
Cc: steven.churchill@ootao.com; andy.dale@ootao.com
Subject: [xdi] notifications for XDI? (was Re: prototype and
consequent feedback on XDI primitive)
Dear All,
reading Andy's reply I realized to haven't been so clear with my use case; I'm
sorry for this, I'll try again to better explain this idea.
The issue we're facing is that there should be some cases in which the terminal
or the device running the CLIENT side of the XDI framework might be needed of
be notified whenever certain data change. This is quite common in
telecommunications environments.
[=Drummond] Yes, I agree with this use case.
For example, OMA XDM ( http://www.openmobilealliance.org/release_program/docs/XDM/V1_0-20060612-A/OMA-TS-XDM_Core-V1_0-20060612-A.pdf )
"defines the common protocol for access and manipulation of XML documents
by authorized principals. This specification reuses the IETF XML Configuration
Access Protocol (XCAP).
XCAP defines:
A convention for describing elements and attributes of an XML
document as a HTTP resource, i.e., accessible via an
HTTP URI
A technique for using HTTP GET, PUT and DELETE methods for
various document manipulation operations (e.g.,
retrieving/adding/deleting elements/attributes, etc.)
The concept and structure of an XCAP Application Usage by which
service or enabler specific documents can be
described
A default authorization policy for accessing and manipulating
documents"
sounds familiar? Basically XDM/XCAP is roughly similar to XDI/XRI, but with
many limitations
- it can handle just XML documents
- it doesn't define an abstract protocol and binding mechanisms
- it doesn't keep the concept of data link between documents
- ...
Though so "primitive" compared to XDI/XRI, it's the OMA standard to
be used in telco!!!
but the interesting thing is that:
"This specification also defines a technique by which changes to such XML
documents can be conveyed to an XCAP CLIENT. This reuses an IETF-defined SIP
event package by which an XDM Client subscribes to changes to all documents
that it owns."
this feature (subscription/notification) is instead missing in XDI! Why we
don't think at an extension of the current spec to support it?
Two issues to be discussed are:
- usefulness (what you think?)
[=Drummond] I have long felt that XDI notifications are very useful; it has
always my assumption we would specify them.
- feasibility and concrete bindings (do we need to use SIP as a concrete
binding for this purpose? Maybe we can rely on the RSS protocol? Etc.)
[=Drummond] This is what needs the most discussion. Both SIP and RSS have
something to offer.
(It is even trivial to say that in case of positive reactions we'll be more
than happy to take the task of writing a (more or less formal) document to
propose such an extension!)
[=Drummond] That would be most welcome. As the minutes of the XRI/XDI TC
meeting in San Diego indicated, we are about to formally update the XDI TC
charter. I’ll be sending more email about that this week. Once we’ve done
that and have the rest of the XRI 2.x Working Drafts ready, I’d really like
to move forward rapidly with drafting the XDI 1.0 specs.
[=Drummond] Are you thinking that this would need to be a separate
specification, or included under the XDI Protocols and Bindings specification
as listed on http://wiki.oasis-open.org/xdi/CharterRevision02
?
Your comments will be welcome!!! (unfortunately I'll be out of office next
week, so time of reaction will be not elevated; however, I've just given the
kick-off :-)
[=Drummond] And I will be out of the office most of this coming week at the
Higgins f2f in Austin, but I’ll be online there, and will be sending out
XRI/XDI TC messages in preparation for our regular telecon this coming
Thursday.
Best,
=Drummond