[standards-jig] LAST CALL: Service Discovery (JEP-0030)

Jeremy Nickurak atrus at rifetech.com
Tue Dec 3 17:52:03 UTC 2002

If a non-disco solution was to be persued, I really don't think it
should be JEP-0013. In order to cover the range of possibile
applications I'm thinking of, a much more generic procotol would be in
order, in particlar, with no references to offline storage, pop, etc. As
well, such a protocol would probabbly benifit from some further
managment utilities, such as the ability to add/remove/move items around
in a hierarchy. While I do think disco could benifit from some of that
remote-editability, it may be too much for a simple protocol.

A new archive/mailbox reading jep might be a better way to go about it,
that would implement the offline-message reading ability of JEP-0013
along the way. I was just hoping that disco might accomplish the same
thing, and therefore provide a little more universal client support.

On Tue, 2002-12-03 at 09:53, Matthew A. Miller wrote:
> On first read, this sounds similar to "POP3 Handling of Offline
> Messages" (aka JEP-0013)[1].  In any case, it's not something that disco
> need do itself, but that another extension protocol (disco-able, of
> course!) could handle, on top of disco (e.g. disco provides the
> hierarchy, and this extension provides semantics for content retrieval).
> [1] http://www.jabber.org/jeps/jep-0013.html
> On Mon, 2002-12-02 at 18:22, Jeremy Nickurak wrote:
> > I know it's kind of late for such a feature, but I'd like to hear if
> > anybody thinks this would be appropriate.
> > 
> > Some time ago I had a discussion with several people on jdev at c.j.o over
> > the idea of browsing newsgroups, mailing lists, imap mailboxes, etc,
> > over jabber. It occurs to me that each of these has the potential for a
> > hierachical organization of items. In particular, jids, perhaps in the
> > form mail.jabber.org/lists/standards-jig can easilly represent
> > folders/lists/groups. This could relatively easilly fit into the disco
> > proposal.
> > 
> > What would become more difficult, as I see it, would be the actual
> > content, in particular, messages, since they don't have an obvious JID
> > scheme. Such a scheme could be invented, against the packet id's, or
> > something similar.
> > 
> > Does anyone have any opinions on whether or not the storage of things
> > like message packets could be fit into the disco scheme without too much
> > trouble? At first glance, i'd suggest that other top-level stream
> > elements (like presence) might not be appropriate, however doing so
> > could allow things like complete mu-conference logs. The creation of a
> > standard means of displaying such archives/lists and the relevant
> > content would also be useful because it could allow clients that don't
> > yet have it to kill two birds with one stone: writing code to browse
> > their own logs as well as conferences, mailboxes, etc.
> > 
> > Admitidly, this is well outside the scope of "Service Discovery" (at
> > least as far as it's name is concerned), but nonetheless it seems to
> > hold potential as an ideal delivery architecture for such archives of
> > elements, without receiving the entire mass of complete messages with
> > body. In addition, I think the ability of disco to be adapted to things
> > like email, newsgroup, and mailing-list reading in the very near future
> > with a relatively simple set of components would be a major incentive
> > for client writers to support what has occasionally been called "just
> > another iq:browse".
> > 
> > Direct flames/insults to me. Anything more positive, please share on
> > standards-jig :)
Jeremy Nickurak <atrus at rifetech.com>

More information about the Standards mailing list