[standards-jig] calendaring?

Dave dave at dave.tj
Wed Mar 13 23:40:20 UTC 2002


Reply inline:

Julian Missig wrote: > > The current routing method. I was just proposing
using browse for very > basic routing. If resource x is the only resource
which support > jabber:iq:negiotiate:video, then it shouldn't be sent
to resource y.  ...but the current routing method is rather severely
limited in its ability to accomodate multiple simultaneous resources :-(

> > Also, in your previous message what you you mean by "Furthermore, >
"enhancing" the browse method to support clients would probably create
a > large argument later"? My proposal would require no changes to the
> browse protocol, it's just an augmentation of the current routing >
method.  I said "enhancing" because I knew that saying enhancing (with
no quotes) would trigger an argument.  The end result is that you're
expanding the browsing protocol to include servers browsing clients,
and making routing decisions based on the results.  Let's not bicker
about wording ;-)

> > For reference, the current routing method is: > 1) Specified resource
> 2) priority > 3) most recently logged in ...and none of those are
terribly useful if I want to have all videoconferencing events sent to
a particular resource, without having to tell all my friends to use that
resource explicitely :-(

> > On Wed, 2002-03-13 at 17:53, Dave wrote: > > ...but what about
my example below, of a text-and-videoconferencing > > client and a
text-only client?  How is the server supposed to guess > > which client
the user wants to receive text messages on (or both)?  > > > >  - Dave
> > 
> > 
> > Julian Missig wrote:
> > > 
> > > That's where feature negotiation comes in. I'll write up some of my
> > > ideas in more detail, but basically, even with simple browsing we could
> > > have the server be properly routing this stuff... the server browses to
> > > the clients as they connect, and if a message with an extension is sent
> > > to the JID with no resource, the server will look at all the resources
> > > for one which reports supporting that namespace.
> > > 
> > > Julian
> > > 
> > > On Wed, 2002-03-13 at 15:50, Dave wrote:
> > > > The problem is that if you have a message-only Jabber client and a
> > > > message-and-videoconferencing Jabber client, you have no way of telling
> > > > the Jabber server that videoconferencing requests should be sent to
> > > > your videoconferencing client, while text messages should be sent to
> > > > your text-only client.  Now, if we add a calendaring client to the mix,
> > > > we've just made our problem even bigger, because we have no way of
> > > > telling the server to send calendaring events to our calendaring client.
> > > > 
> > > > In other words, you're right: there's nothing "requiring" a Jabber client
> > > > to implement a non-core feature (or even the "core" feature of text
> > > > messaging), but if your client doesn't implement a particular feature,
> > > > users of that client won't have an easy way of using that feature without
> > > > opting for another client for _all_ their Jabber interaction.  THAT is
> > > > what I'm referring to as the problem here.  I'm working on a solution
> > > > with my Jabber proxy, but I'd like to see my proxy obsoleted by some
> > > > server-side ability to route XML data to different resources based on
> > > > rules submitted by the clients.  I'd like to have my calendaring Jabber
> > > > "client" actually be a module in my calendaring application, designed
> > > > to interact with the Jabber world.  I can then have a module in my
> > > > calendaring application for email interfacing (which already has very
> > > > impressive routing capabilities) too, as well as one for communicating
> > > > over my cell phone.
> > > > 
> > > > Dave Cohen <dave at dave.tj>
> > > > 
> > > > 
> > > > Iain Shigeoka wrote:
> > > > > 
> > > > > On 3/5/02 8:42 AM, "Dave" <dcohen at ramapo.edu> wrote:
> > > > > 
> > > > > > If your goal is to be able to "chat" with your calendar, I'd strongly
> > > > > > suggest using something like ChatBot, and simply making a scheduling
> > > > > > plugin.  If your goal is to integrate scheduling functionality into
> > > > > > a Jabber client, why not just embed a calendaring client (for some
> > > > > > reasonably standardized scheduling protocol) into your Jabber client?
> > > > > > As far as I can see, the more "stuff" we add to the Jabber protocol,
> > > > > > the fewer choices we'll all have for fully-functional clients
> > > > > > (since a "fully-functional" Jabber client will actually have to be a
> > > > > > fully-functional video conferencing client, as well as a fully-functional
> > > > > > scheduling client, as well as a fully-functional group management client,
> > > > > > as well as, of course, a fully-functional IM client, and my experience
> > > > > 
> > > > > This is not the intent of the Jabber protocol setup.  Other than the basic
> > > > > Jabber protocols, all other protocols are optional.  There may be
> > > > > "competing" protocols which address the same problem in different ways.  As
> > > > > long as you support the "core" jabber protocols, you are a "full jabber
> > > > > client".  All extension protocols are designed to provide standard ways of
> > > > > adding additional functionality.  They are not required or even suggested
> > > > > for every client to implement.
> > > > > 
> > > > > All this goes to say that within reason, the more protocols the better.  A
> > > > > calendering protocol would be a nice addition.
> > > > > 
> > > > > -iain
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 




More information about the Standards mailing list