[standards-jig] calendaring?

Julian Missig julian at jabber.org
Wed Mar 13 21:00:14 UTC 2002


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





More information about the Standards mailing list