[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [JDEV] Contact Methods



On Fri, 30 Apr 1999, Thomas Charron wrote:

> 
> 	No reason a client couldn't do this.  As a matter of fact, we could have an
> 'alternate address' list as part of the users status information, and have
> the transport have a 'fallback' option.
> 

interesting idea.

> 
> 	Idea's?  Comments?  There could also be information stored in status, so
> when a person adds a user, it would be able to parse out additional
> addresses for this person and automagically add them as alternates.  This
> would also NOT break clients who didn't support alternate addy's, as the
> data is stored in <ext>, so they'll just look like normal roster entries to
> dumber clients..  Might get ugly with 20 people with 3 alternate's, though..
> 

plain jane, the functionality i'd like to see (and i wouldn't mind working
on the design and implementation myself ;) is that with a person in my
contact list, a tree view for that entry could pop up with the alternates.
i just want to be able to see in that entry for the person (user definable
name, but the contact list entry would be a jabber address) the alternate
modes of contact, and, if i choose, send a message to that person's pager
only.  most importantly, i don't want to know the details of what that
pager's ID number is or what the pager's phone number is.  this would all
be defined by the user on the other end (and stored at the server).  i'm
really infatuated with the Pager transport (may even work on it myself) as
I've had experience with sendpage (popular paging program) and creating a
gateway to it via the web.

> 	Perhaps something like this instead?
> 
>   <roster>
>     <group name="main">jenny<ext><Alternate
> number=1/>545212@ICQ</ext></group>
>     <group name="friends">user@jabber.server.com</group>
>     <group name="system">olduser</group>
>   </roster>
> 
> 	This MIGHT be a better way, as dumber clients would now only have one
> entry, without the alternate contact methods..
> 

there has to be some way to do this and still keep the client work to a
minimum..

Chase Phillips
--
  shepard at ameth.org ][ Only you will know
 http://www.ameth.org/ ][ if I proofread this