[standards-jig] calendaring?

Dave dave at dave.tj
Thu Mar 14 00:08:18 UTC 2002


Talk about an email formatter gone mad ... LOL. . .
(I guess I've got a new bug to work on fixing.)

 - Dave


Dave wrote:
> 
> 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
> > 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 




More information about the Standards mailing list