[ticker-dev] ticker-3.0 & presence spec

[Ian Lister]

On Thu, 11 Apr 2002, Wanicki, Martin wrote:
>I like this as a concept, *but* I dont want to have to emit multiple
>scope-based notifications.

If you don't want to implement it in eTiks you don't have to. There's no
need for it to be mandatory.

>as an example - in eTiks when you use the optional extra attribute  (I use
>for domain scoping), it gets
>appended to EVERY emitted notification INCLUDING presence,
>so I can set my presence info to "unavailable" for the world to receive,
>then turn on the domain restriction attribute and send an
>"available"
>
>the net result being the world thinks I'm unavailable and until I turn of
>the domain restriction attribute, will continue to do so.

Of course this only sort-of works, as subsequent requests by external
people won't get any response from you. You can choose to stick with this
way of dealing with it if you like, but my proposal allows other users to
get extra value out of the protocol.

>changing a setting for a single status change to reflect all the different
>ways I want this status change to be seen by different people
>in different domains seems to be a little broken to me, perhaps I'm
>misunderstanding.

I'm not quite sure what you mean. How this functionality is presented to
the user (if at all) is up to anybody who wants to implement it. It seems
to me that if you want different people to see different things you have
to specify both of those different things somehow. It's an open question
exactly how - you could have your client preconfigured with rules (like
your `Meeting', `(Meeting)' stuff), or you could have a separate agent
(bot, if you like) on the network doing that (as you proposed). Either
way, I think adding the Distribution tag only enables these things, and
allows clients to deal with it as they like (if at all).

>The answer here seems to indicate a personal presence bot, that see's only
>my presence info's and based on rules
>emits the appropriate presence notification, properly scoped.
>I certainly dont have the time or inclination to build this into etiks,
>although this functionality *may* be desirable.

As above, I think this allows a personal presence bot (translating your
organisation-local notifications to global ones). It also allows the
functionality to built into the end-user's presence client if you want.

>One could, of course, run multiple clients, each configured differently, but
>i dont think thats the answer either.

It's an answer, but probably not ideal for the user :-)

>Distribution for presence doesnt really seem do-able,

I don't agree.

>I think we have a case for domain policy here in defining the status
>descriptions that are allowable within a domain
>something along the lines of the following .
>
>	the status description "Meeting" is allowed beyond the domain
>perimiter, but the
>	the status description "(Meeting)" is NOT allowed beyond the domain
>perimiter.

That is certainly one approach, and is not at all incompatible with my
suggestion.

>I dunno what the answer is, it'd be really good if we could keep it simple
>and elegant :-)

Sure - I'm all for that too! :-)

Ian