Net-RVP

 view release on metacpan or  search on metacpan

client.pl  view on Meta::CPAN

    $users->{lc $user->name()} = $user;
  }
}
if($renew) {
  my $ival = $renew-(time-$start)-30;  # 30 seconds short of timing out
  Event->timer(interval => ($ival < 1 ? 1 : $ival), cb => sub {
   $_->watch() for values %$users; });
}

=pod
my @state = qw(offline online idle on-phone at-lunch busy);
Event->timer(interval => 60,
 cb => sub { $rvp->status($state[rand @state]) });
=cut

# add a STDIN I/O event
if(my $flags = fcntl(STDIN,F_GETFL,pack '') >= 0) {
  fcntl(STDIN,F_SETFL,$flags | O_NONBLOCK);
}
Event->io(fd => \*STDIN, poll => 'r', cb => \&stdin_read_event);

docs/RVP_specification.txt  view on Meta::CPAN

          8. Return codes .............................................. 31 
          9. XML Document Type Definition .............................. 32 
             9.1  RVP elements ......................................... 33 
                9.1.1 State ............................................ 33 
                9.1.2 leased-value ..................................... 33 
                9.1.3 default-value .................................... 33 
                9.1.4 value ............................................ 33 
                9.1.5 online ........................................... 33 
                9.1.6 offline .......................................... 33 
                9.1.7 away ............................................. 34 
                9.1.8 busy ............................................. 34 
                9.1.9 back-soon . ...................................... 34 
                9.1.10   on-phone ...................................... 34 
                9.1.11   at-lunch ...................................... 34 
                9.1.12   view-id ....................................... 34 
                9.1.13   principal ..................................... 34 
                9.1.14   rvp-principal ................................. 34 
                9.1.15   email ... ..................................... 34 
                9.1.16   mobile-state .................................. 35 
                9.1.17   mobile-description ............................ 35 
                9.1.18   notification .................................. 35 

docs/RVP_specification.txt  view on Meta::CPAN

          the requested timeout is not permitted by its admin policy.

          As there may be multiple PRESENTITYs setting properties for a
          certain node (i.e. User logs in from multiple machines), the XML
          schema allows for a view identifier element to be specified in
          the PROPPATCH requests and responses. This allows state changes
          to be replicated amongst all PRESENTITYs, and certain states to
          be specific to a PRESENTITY.

          For example if a PRINCIPAL has multiple PRESENTITYs logged in,
          any state changes to be “busy”, or “out to lunch”, will result in
          all PRESENTITYs being notified of this status change. However if
          a certain PRESENTITY became offline or idle, then no other
          PRESENTITYs would be notified of this status change, and the
          PRINCIPAL would remain online at a different PRESENTITY.

          When a PROPPATCH request does not contain a view identifier, a
          successful response will include one. This identifier is unique
          to that leased property, and any subsequent PROPPATCH requests
          that specify the view identifier. If all leased properties, with
          that view identifier, expire then it is no longer valid and

docs/RVP_specification.txt  view on Meta::CPAN

       9.1.3 default-value

          Definition:  <!Element default-value ANY>
          Parent:      <leased-value>

       Osborne et al                                                       32

                                        RVP

          Purpose:     To indicate the current default status of the node
                       (currently one of “<online> <offline> <away> <busy>”
                       <back-soon> <on-phone> or <at-lunch>)

       9.1.4 value

          Definition:  <!Element value ANY>
          Parent:      <leased-value>
          Purpose:     To indicate the current status of the node
                       (currently one of “<online> <offline> <away> <busy>”
                       <back-soon> <on-phone> or <at-lunch>)

       9.1.5 online

          Definition:  <!Element online EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the online status

       9.1.6 offline

          Definition:  <!Element offline EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the offline status

       9.1.7 away

          Definition:  <!Element away EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the away status

       9.1.8 busy

          Definition:  <!Element busy EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the busy status

       9.1.9 back-soon

          Definition:  <!Element back-soon EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the back soon status

       9.1.10 on-phone

          Definition:  <!Element on-phone EMPTY>

docs/draft-calsyn-rvp-01.txt  view on Meta::CPAN

          when the client goes offline, for any subscriptions listed as
          such.
          Issues:  Can one person subscribe another person?  How should we
          handle Reply-Tos that are different from the subscription
          requester?

       5.1.8.    Multiple client issues

          The issues for multiple clients connected at the same time
          haven't been worked out yet.  Which ones should receive instant
          messages?  If one client is "idle" and one client is "busy" what
          is the user marked as?

          Is there any way for another user to query the status of a
          particular client?  E.g. to see if the desktop is idle while the
          laptop is active & vice-versa?  Also, idea of addressing IM's to
          a particular online client?

          If multiple clients are connected, and the home server refers to
          one client, that client is primary.  Other clients must send
          their status to the primary client.

docs/draft-calsyn-rvp-01.txt  view on Meta::CPAN

          RVP/1.0 207 SUBSCRIBE
          RVP/1.0 ??? REFER  (or we could use 302 "Moved Temporarily")

          Existing HTTP/1.1 responses used in RVP:

          HTTP/1.1 400 Bad Request  (bad syntax)
          HTTP/1.1 401 Unauthorized (Need to get authenticated first)
          HTTP/1.1 402 Forbidden (ACLs forbid user to do that)
          HTTP/1.1 404 Not Found (object or property not found)
          HTTP/1.1 501 Not Implemented (method not understood by server)
          HTTP/1.1 503 Service Unavailable (i.e. too busy)

       10.4.     Proxying and Referral

          The default behavior for a RVP object on a server is for that
          server to respond to queries and subscriptions and receive
          instant messages for that object.  However, there are exceptional
          circumstances.  Both servers and clients can optionally support
          these features.

          Each RVP object may have a property named "LINK".  The value of



( run in 0.248 second using v1.01-cache-2.11-cpan-3cd7ad12f66 )