Do you follow semantic versioning as defined by semver.org? If yes, can you mention it is README. If not, can you consider it?

While 1.3.1 fixed the problem where the rooms method returned an empty array, I'm now getting an undefined method 'map' for nil::NilClass when I call the rooms method. Here's some irb output to illustrate the issue:

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'tinder'
=> true
irb(main):003:0> campfire = Tinder::Campfire.new 'domain', :ssl => true
=> #<Tinder::Campfire:0x5cc41d8 @cookie=nil, @logged_in=false, @connection=#Tinder::Connection:0x5cc40c0, @http=Net::HTTP, @uri=#<URI::HTTPS:0x5cbf048 URL:https://domain.campfirenow.com>, @subdomain="domain">
irb(main):004:0> campfire.login 'myusername', 'mypass'
=> true
irb(main):005:0> campfire.rooms
NoMethodError: undefined method map' for nil:NilClass from /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/tinder-1.3.1/lib/tinder/campfire.rb:62:inrooms'
from (irb):5
from :0

I have tried this with both httparty 0.5.0 and 0.4.3 with the same result. Also note that I'm using enterprise ruby, if that makes a difference.

Thanks, and I definitely concede that this could be due to operator error :) But it has been working well for a long time. Just not of late.

• Jeremy

In your MIT-LICENSE file there are several typos:

e.g.
line 16: PURPOa => PURPOSE
line 17: SaALL => SHALL

Could you please copy it again from http://www.jclark.com/xml/copying.txt and
release a new version of tinder on rubygems.

We would like to add it into Debian, but this is only possible if the license and copyright is correct.

I looked in the readme file and even at a few of the source files under lib/ and I found no indication of what terms tinder is distributed under.

after a successful login from irb (.login returns true), I am getting the following. This room name is correct and the room currently exists. (It is a private room in my subdomain).

irb(main):011:0> room = campfire.find_room_by_name 'Puppet Labs'
NoMethodError: undefined method map' for nil:NilClass from /var/lib/gems/1.8/gems/tinder-1.3.1/lib/tinder/campfire.rb:62:inrooms'
from /var/lib/gems/1.8/gems/tinder-1.3.1/lib/tinder/campfire.rb:69:in find_room_by_name' from (irb):11 from �:0 irb(main):012:0> campfire.find_room_by_name("Puppet Labs") NoMethodError: undefined methodmap' for nil:NilClass
from /var/lib/gems/1.8/gems/tinder-1.3.1/lib/tinder/campfire.rb:62:in rooms' from /var/lib/gems/1.8/gems/tinder-1.3.1/lib/tinder/campfire.rb:69:infind_room_by_name'
from (irb):12
from �:0
irb(main):013:0> campfire.find_room_by_name("PuppetLabs")
NoMethodError: undefined method map' for nil:NilClass from /var/lib/gems/1.8/gems/tinder-1.3.1/lib/tinder/campfire.rb:62:inrooms'
from /var/lib/gems/1.8/gems/tinder-1.3.1/lib/tinder/campfire.rb:69:in find_room_by_name' from (irb):13 from �:0 irb(main):014:0> room = campfire.find_room_by_name("Puppet Labs") NoMethodError: undefined methodmap' for nil:NilClass
from /var/lib/gems/1.8/gems/tinder-1.3.1/lib/tinder/campfire.rb:62:in rooms' from /var/lib/gems/1.8/gems/tinder-1.3.1/lib/tinder/campfire.rb:69:infind_room_by_name'
from (irb):14
from �:0

Any ideas? Thanks!

I'm trying to use tinder to post a message, and the code is executing with no exceptions, but no message is appearing in the room. Any idea what could cause this? I've already double-checked the room id value.

After adding some logging lines to figure out what is going on, I realized that campfire's streaming API occasionally closes idle connections with a 400 error status code. When the disconnect happens, tinder picks up an error in its 'on_error' handler and raises a "ListenFailed" error.

This is somewhat reasonable behavior, though, Campfire's Streaming API documentation notes that "API clients must be able to handle occasional timeouts or disruptions. Upon unexpected disconnection, API clients should wait for a few seconds before trying to reconnect." It doesn't seem that tinder follows this contract.

Thoughts? Happy to submit a patch, but wanted to make sure my understanding is correct first.

Hey,

When I do something like:

@room = @campfire.find_room_by_name("lala")

@room.speak(params[:message])

then the message is sent, but I need to refresh the "lala" room on campfire to see the message.
Is that normal?
Just so you know, another app is listening to the room and send incoming messages to all the clients listening using juggernaut.

Thx

The campfire API includes the room's creation date, Tinder doesn't seem to expose this, near as I can tell. This has some value in terms of finding out how far back to dig for transcripts.

campfire = Tinder::Campfire.new 'mysite', :token => '000000000000000'
campfire.create_room "testing"
=> nil

Not sure why the room wont create, this token is for an admin user. Is there any other config that is needed?

speak method just returns 'false' (I'm using only token as my ID, blank pw).

Works fine with httparty 0.4.3

Could you please push out a new release with the relaxed Hashie dependency? I have dependency conflicts almost every time I use tinder, and now have a gem that uses tinder itself so the conflict is even tougher to work around. Would be great to reference a published gem version.

Hashie (https://github.com/intridea/hashie) is getting ready to turn 2.0 (currently 2.0.0-beta). Tinder specifies that it uses Hashie ~> 1.0.

It'd be awesome if I could use Hashie 2.0.0-beta AND Tinder on the same project, but right now, I have to use Tinder from a fork to change the gem dependency.

Time to refresh this gem!

When joining and streaming a campfire room, a value of 6 seconds is passed into JSONStream, which is a too little value.

At this moment, 37Signals is sending a 1 value every 3 seconds to keep open the connection, so if one of these keep-alive packets is lost or delayed the client closes the connection and Twitter::JSONStream raises the following error:

/app/vendor/bundle/ruby/2.0.0/gems/twitter-stream-0.1.16/lib/twitter/json_stream.rb:131:in `<<': Could not parse data entirely (HTTP::Parser::Error)
   from /app/vendor/bundle/ruby/2.0.0/gems/twitter-stream-0.1.16/lib/twitter/json_stream.rb:131:in `receive_data'
   from /app/vendor/bundle/ruby/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
   from /app/vendor/bundle/ruby/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
   from /app/vendor/bundle/ruby/2.0.0/gems/thin-1.5.1/lib/thin/backends/base.rb:63:in `start'
   from /app/vendor/bundle/ruby/2.0.0/gems/thin-1.5.1/lib/thin/server.rb:159:in `start'
   from /app/vendor/bundle/ruby/2.0.0/gems/lita-2.3.0/lib/lita/robot.rb:98:in `block in run_app'

I've forked the repo and tried with a higher value ( 60 ) and no disconnection has happened yet.

while testing your library tinder for Debian, with the following dependencies:

ruby2.1 (2.1.2-2)
ruby (1:2.1.0.1)
ruby-diff-lcs (1.2.5-1)
ruby-fakeweb (1.3.0+git20131202.48208f9+dfsg-1)
ruby-multipart-post (1.2.0-2)
ruby-faraday (0.9.0-2)
ruby-faraday-middleware (0.9.1-1)
ruby-hashie (2.0.5-1)
ruby-mime-types (1.25-2)
ruby-multi-json (1.10.0-1)
ruby-rspec-expectations (2.14.2-1)
ruby-rspec-mocks (2.14.5-1)
ruby-rspec-core (2.14.7-2)
ruby-rspec (2.14.1-1)
ruby-simple-oauth (0.2.0-2)
ruby-eventmachine (1.0.3-6+b1)
ruby-http-parser.rb (0.6.0-2+b2)
ruby-json (1.8.1-1+b1)
ruby-twitter-stream (0.1.16-1)

the following error happens:

Failures:

  1) Tinder::Connection ssl should allow passing any ssl_options to Faraday
     Failure/Error: connection.connection.ssl.should eql(:verify => false, :ca_path => "/usr/lib/ssl/certs", :ca_file => "/etc/ssl/custom")

       expected: {:verify=>false, :ca_path=>"/usr/lib/ssl/certs", :ca_file=>"/etc/ssl/custom"}
            got: #<Faraday::SSLOptions ca_file="/etc/ssl/custom", ca_path="/usr/lib/ssl/certs">

       (compared using eql?)

       Diff:
       @@ -1,4 +1,13 @@
       -:ca_file => "/etc/ssl/custom",
       -:ca_path => "/usr/lib/ssl/certs",
       -:verify => false
       +#<struct Faraday::SSLOptions
       + verify=false,
       + ca_file="/etc/ssl/custom",
       + ca_path="/usr/lib/ssl/certs",
       + verify_mode=nil,
       + cert_store=nil,
       + client_cert=nil,
       + client_key=nil,
       + certificate=nil,
       + private_key=nil,
       + verify_depth=nil,
       + version=nil>
     # /usr/lib/ruby/vendor_ruby/rspec/expectations/fail_with.rb:32:in `fail_with'
     # /usr/lib/ruby/vendor_ruby/rspec/expectations/handler.rb:34:in `handle_matcher'
     # /usr/lib/ruby/vendor_ruby/rspec/expectations/syntax.rb:53:in `should'
     # ./spec/tinder/connection_spec.rb:101:in `block (3 levels) in <top (required)>'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:114:in `instance_eval'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:114:in `block in run'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:254:in `with_around_each_hooks'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:111:in `run'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:390:in `block in run_examples'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:386:in `map'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:386:in `run_examples'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:371:in `run'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:372:in `block in run'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:372:in `map'
     # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:372:in `run'
     # /usr/lib/ruby/vendor_ruby/rspec/core/command_line.rb:28:in `block (2 levels) in run'
     # /usr/lib/ruby/vendor_ruby/rspec/core/command_line.rb:28:in `map'
     # /usr/lib/ruby/vendor_ruby/rspec/core/command_line.rb:28:in `block in run'
     # /usr/lib/ruby/vendor_ruby/rspec/core/reporter.rb:58:in `report'
     # /usr/lib/ruby/vendor_ruby/rspec/core/command_line.rb:25:in `run'
     # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:80:in `run'
     # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:17:in `block in autorun'

Finished in 0.10882 seconds
51 examples, 1 failure

Failed examples:

rspec ./spec/tinder/connection_spec.rb:88 # Tinder::Connection ssl should allow passing any ssl_options to Faraday
/usr/bin/ruby2.1 -S rspec ./spec/tinder/campfire_spec.rb ./spec/tinder/connection_spec.rb ./spec/tinder/room_spec.rb failed

Could you please have a look?

On ruby 1.8.7 (2011-02-18 patchlevel 334) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2011.03,

 irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'tinder'
NoMethodError: undefined method `delegate' for #<Class:ActiveSupport::JSON>
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/gems/1.8/gems/activesupport-2.3.9/lib/active_support/json/decoding.rb:13
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/gems/1.8/gems/activesupport-2.3.9/lib/active_support/json.rb:1
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/gems/1.8/gems/tinder-1.7.0/lib/tinder/connection.rb:2
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/gems/1.8/gems/tinder-1.7.0/lib/tinder.rb:2
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
    from /usr/local/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
    from (irb):2

Installed gems:

 gem list

*** LOCAL GEMS ***

activesupport (2.3.9)
addressable (2.2.6)
eventmachine (0.12.10)
faraday (0.7.5)
faraday_middleware (0.7.0)
hashie (1.2.0)
http_parser.rb (0.5.3)
mime-types (1.16)
multi_json (1.0.3)
multipart-post (1.1.3)
rack (1.3.5)
simple_oauth (0.1.5)
tinder (1.7.0)
twitter-stream (0.1.14)

The gem does not constrain correctly its dependencies.

Hi,

Ruby2.7 was recently released and it'd be great to have that support here.
I am not sure if you still want to maintain this gem anymore, but it'd be great if you could help :D

Using 1.4.4 I could connect to a room and listen to it fine, but switching to 1.5.0 breaks it. I haven't had time to investigate possible causes yet, but based on other issues I've experienced with Faraday I suspect it's that the oAuth headers aren't being generated properly. Will look in to it more soon.

When using tinder with ActiveSupport 2.3, you get whack-a-mole errors from various ActiveSupport internal dependencies not being loaded. I think it started with this commit.

3b34bb0#lib/tinder/connection.rb

Since the top-level active support require was removed, then the dependencies of ActiveSupport::JSON never get loaded with AS 2.3.

I keep getting this error and crashing when I try to use the Tinder::Room listen method.. can someone please help?

Trying to create a simple bot to listen in a room and upload an image. Every time I call the upload method, I get the following backtrace.

got an error! "NoMethodError: undefined method `bytesize' for #\n\t/Users/jmeskill/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/net/http.rb:1735:in `send_request_with_body'\n\t/Users/jmeskill/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/net/http.rb:1724:in `exec'\n\t/Users/jmeskill/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/net/http.rb:1189:in `transport_request'\n\t/Users/jmeskill/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/net/http.rb:1177:in `request'\n\t/Users/jmeskill/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/net/http.rb:1170:in `block in request'\n\t/Users/jmeskill/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/net/http.rb:627:in `start'\n\t/Users/jmeskill/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/net/http.rb:1168:in `request'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/faraday-0.7.5/lib/faraday/adapter/net_http.rb:62:in `call'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/faraday-0.7.5/lib/faraday/response.rb:8:in `call'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/faraday-0.7.5/lib/faraday/response.rb:8:in `call'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/faraday-0.7.5/lib/faraday/response.rb:8:in `call'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/faraday-0.7.5/lib/faraday/response.rb:8:in `call'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/faraday-0.7.5/lib/faraday/connection.rb:207:in `run_request'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/faraday-0.7.5/lib/faraday/connection.rb:94:in `post'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/tinder-1.7.0/lib/tinder/connection.rb:92:in `raw_post'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/tinder-1.7.0/lib/tinder/room.rb:251:in `raw_post'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/tinder-1.7.0/lib/tinder/room.rb:210:in `upload'\n\tmybot.rb:22:in `block in listen'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/tinder-1.7.0/lib/tinder/room.rb:158:in `block (2 levels) in listen'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:277:in `call'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:277:in `parse_stream_line'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:208:in `block in receive_stream_data'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:207:in `each'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:207:in `receive_stream_data'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:121:in `call'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:121:in `<<'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:121:in `receive_data'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'\n\t/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/tinder-1.7.0/lib/tinder/room.rb:151:in `listen'\n\tmybot.rb:20:in `listen'\n\tmybot.rb:32:in `'"!
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/tinder-1.7.0/lib/tinder/room.rb:162:in `block (2 levels) in listen'
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:268:in `call'
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:268:in `receive_error'
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:212:in `rescue in receive_stream_data'
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:206:in `receive_stream_data'
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:121:in `call'
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:121:in `<<'
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/twitter-stream-0.1.14/lib/twitter/json_stream.rb:121:in `receive_data'
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'
/Users/jmeskill/.rvm/gems/ruby-1.9.2-p290@scrumbot/gems/tinder-1.7.0/lib/tinder/room.rb:151:in `listen'
mybot.rb:20:in `listen'
mybot.rb:32:in `'

Here's my code:

require 'rubygems'

require 'tinder'

class Mybot

  CAMPFIRE_SUBDOMAIN = 'subdomain'
  CAMPFIRE_TOKEN = 'abcdef00000'
  CAMPFIRE_ROOM  = 'A Room'

  def campfire
    @campfire ||= Tinder::Campfire.new(CAMPFIRE_SUBDOMAIN, :token => CAMPFIRE_TOKEN)
  end
  
  def room
    @room ||= campfire.find_room_by_name(CAMPFIRE_ROOM)
  end
  
  def listen
    room.listen do |m|
      if m[:body] =~ /trollface/i
        room.upload('trollface.png')
      end
    end
  end
end


begin
  mybot = Mybot.new

  mybot.listen
rescue => e
  puts e.message
  puts e.backtrace.join("\n")
  exit
end

Currently Tinder Boost is rolled out in Australia to boost the visibility of your profile. In the past Tinder rolled out the UI of features in Australia first, but the features have been active for all countries.

Can somebody in Australia discover the API call of the Boost Feature with Charles Proxy or another proxy so the boost api can be added to the software?

As long as UI is not rolled out in every country activating this will give you much more boost than when it's live because there's no competition for your bots 😁

Create room doesn't work:

campfire.create_room "test room", "test room topic"
=> nil

What's up?

Ruby 1.8.7
Tinder installed as a Rails plugin

NoMethodError: undefined method bytesize' for #<Hash:0x00000002d5c800> from /usr/lib/ruby/1.9.1/net/http.rb:1932:insend_request_with_body'
from /usr/lib/ruby/1.9.1/net/http.rb:1919:in exec' from /usr/lib/ruby/1.9.1/net/http.rb:1317:inblock in transport_request'
from /usr/lib/ruby/1.9.1/net/http.rb:1316:in catch' from /usr/lib/ruby/1.9.1/net/http.rb:1316:intransport_request'
from /usr/lib/ruby/1.9.1/net/http.rb:1293:in request' from /usr/lib/ruby/1.9.1/net/http.rb:1286:inblock in request'
from /usr/lib/ruby/1.9.1/net/http.rb:745:in start' from /usr/lib/ruby/1.9.1/net/http.rb:1284:inrequest'
from /var/lib/gems/1.9.1/gems/faraday-0.8.7/lib/faraday/adapter/net_http.rb:75:in perform_request' from /var/lib/gems/1.9.1/gems/faraday-0.8.7/lib/faraday/adapter/net_http.rb:38:incall'
from /var/lib/gems/1.9.1/gems/faraday-0.8.7/lib/faraday/response.rb:8:in call' from /var/lib/gems/1.9.1/gems/faraday-0.8.7/lib/faraday/response.rb:8:incall'
from /var/lib/gems/1.9.1/gems/faraday_middleware-0.9.0/lib/faraday_middleware/response_middleware.rb:30:in call' from /var/lib/gems/1.9.1/gems/faraday-0.8.7/lib/faraday/response.rb:8:incall'
from /var/lib/gems/1.9.1/gems/faraday-0.8.7/lib/faraday/connection.rb:247:in run_request' from /var/lib/gems/1.9.1/gems/faraday-0.8.7/lib/faraday/connection.rb:112:inpost'
from /var/lib/gems/1.9.1/gems/tinder-1.9.2/lib/tinder/connection.rb:86:in raw_post' from /var/lib/gems/1.9.1/gems/tinder-1.9.2/lib/tinder/room.rb:291:inraw_post'
from /var/lib/gems/1.9.1/gems/tinder-1.9.2/lib/tinder/room.rb:235:in `upload'

According to the Campfire API documentation (http://developer.37signals.com/campfire/), it's expected for clients to set the Content-type header explicitly when sending JSON or XML requests. [I know, it's redundant, the content type should be inferred from the dot-extension of the request.] Occasionally a request that's properly authenticated, but rejected by Campfire for other reasons (possibly the account being disabled), a 302 redirect is returned with an HTML formatted message. This causes a lexical parsing error in YAJL. Following is a stack trace:

MultiJson::DecodeError: lexical error: invalid char in json text. You are being <a hr (right here) ------^
…8/gems/multi_json-1.0.3/lib/multi_json/engines/yajl.rb: 10:in parse' …8/gems/multi_json-1.0.3/lib/multi_json/engines/yajl.rb: 10:indecode'
…undle/ruby/1.8/gems/multi_json-1.0.3/lib/multi_json.rb: 65:in decode' …ay_middleware-0.6.5/lib/faraday/response/parse_json.rb: 16:inparse'
…le/ruby/1.8/gems/faraday-0.6.1/lib/faraday/response.rb: 17:in on_complete' …le/ruby/1.8/gems/faraday-0.6.1/lib/faraday/response.rb: 9:incall'
…le/ruby/1.8/gems/faraday-0.6.1/lib/faraday/response.rb: 62:in on_complete' …le/ruby/1.8/gems/faraday-0.6.1/lib/faraday/response.rb: 8:incall'
…le/ruby/1.8/gems/faraday-0.6.1/lib/faraday/response.rb: 8:in call' …uby/1.8/gems/faraday-0.6.1/lib/faraday/request/json.rb: 28:incall'
…dle/ruby/1.8/gems/faraday-0.6.1/lib/faraday/request.rb: 88:in run' …dle/ruby/1.8/gems/faraday-0.6.1/lib/faraday/request.rb: 28:inrun'
…/ruby/1.8/gems/faraday-0.6.1/lib/faraday/connection.rb: 170:in run_request' …/ruby/1.8/gems/faraday-0.6.1/lib/faraday/connection.rb: 64:inget'
…le/ruby/1.8/gems/tinder-1.7.0/lib/tinder/connection.rb: 82:in get' …ndle/ruby/1.8/gems/tinder-1.7.0/lib/tinder/campfire.rb: 34:inrooms'
…ndle/ruby/1.8/gems/tinder-1.7.0/lib/tinder/campfire.rb: 41:in `find_room_by_id'

Its kinda of annoying, i just wasted an hour trying to login by the old method

Please mark them as deprecated at least.

Thanks.

So, I just broke campfire hooks on GitHub services for a few minutes. I'm testing the unreleased Faraday 0.8 with some real code before I push it out. I actually did add one last minute tweak due to a Tinder test failure. After that, everything passed (even on her). Perfect, ship it!

Boom! It all blew up :(

Part of the reason is I'm actually testing the CF hook by mocking the Tinder classes a bit. So janky.

What do you guys think about something like this:

cf = Tinder::Campfire.stub(campfire_domain, :ssl => true, :token => data['token'])
cf.on_message do |some_shit|
  assert some_shit
end

room = cf.find_room_by_name(blah)
room.speak blah

It could use Faraday::Adapter::Test, and let applications test their integration without hitting Campfire. I'm not super familiar with the codebase, but I'm totally down to make this happen. Just let me know :+1: or :-1: :)

Hi, can you please push a new version in rubygems.org with the updated dependencies (hashie, json, multi_json)?

I am trying to package this for Fedora and this is somehow a stopper, as we already have hashie 2.0.5 and multi_json 1.7.7 in the repos.

Thank you :)

I'm experimenting with the Room#listen method for streaming. It seems like there's a significant delay between someone chatting in the channel actually receiving the message via Room#listen. Is this a known limitation? Is there any way to somehow shorten the delay?

Thanks!

Hi,

faraday_middleware gem dependency has 'locked' faraday gem version to <0.9. This way I am not able to upgrade faraday greater than 0.9...

Please let me know if I am missing something?

Best,
Rastko

Hi-
I love your gem and am using it for http://notifire.me to monitor campfire chat rooms. However, it seems as though rooms that have urls beginning with https as opposed to http are presenting a problem in that I'm not able to connect and constantly monitor.

I'm not sure how to address this as authentication occurs simply by providing the sub-domain, api key, and room id. Do you have any recommendations? Thanks for your help!

Removing ActiveSupport dependency took out the .to_date method

Twitter requires 0.6 but you're requiring 0.5.1. Can't use the Twitter gem in my Tinder scripts.

cijoe throw an error:

Exception building: undefined method `to_json' for #Hash:0x26eff80 (NoMethodError)

I'm trying to build a CF bot and I keep running into a problem where tinder just silently fails for no apparent reason.

I'm finding it difficult to diagnose this problem because there's no crash, or backlog, or error message. The only clue that you get that this has happened is that no messages are being received.

The case seems to be that if any exception happens in the listen block it gets silenced but Tinder stops listening for new messages.

I'm fairly certain that the problem doesn't lie with my code due to the fact that I rescue virtually all possible exceptions inside the listen block and output the error messages directly into our CF room.

Update:

The following (test) code fails silently:

cf = cf = Tinder::Campfire.new("subdomain", :token => "…")
room = cf.find_room_by_name("My Room")
room.listen do |message|
  raise "This should go boom"
end

This is several places in room.rb's comments and in the documentation site, but appears to have been removed from the API provided

The following code in my endpoint was working great a few weeks ago. Code has not changed and now it is returning nil.

    campfire = Tinder::Campfire.new 'subdomain', :token => 'mytoken'
    room = campfire.find_room_by_name 'RoomName'

When I inspect the campfire.rooms I get:

   #<Tinder::Room:0x007fd06a1bb8d0
  @connection=
   #<Tinder::Connection:0x007fd06a1c9b88
    @options={:ssl=>true, :proxy=>nil, :token=>"mytoken"},
    @subdomain="subdomain",
    @token="mytoken",
    @uri=#<URI::HTTPS:0x007fd06a1c97c8 URL:https://subdomain.campfirenow.com>>,
  @id="room_id",
  @loaded=false,
  @name=nil>,

As you can see this one instance of a room object is returning nil for the room attribute. Our group has several rooms, and the weird thing is, the first three return an actual value for the @name attribute where the rest just return nil as is the room that the original query was looking for. I have an open ticket with Campfire, however they mentioned to check you the Tinder team to have you evaluate as well, for they have not changed anything in their API and our user database still lists the correct data for the room we are trying to use. Please let me know if you need more info. Thanks.

faraday promises compatibility with minor updates lostisland/faraday#515 and many libraries already declare a relaxed requirement. Please update dependency to ~> 0.9 so its easier for us to update faraday in debian.

It would be nice to update the eventmachine dependency to:

gem.add_dependency 'eventmachine', [ '>= 0.12.0', '< 1.1' ]

Hi,

Thanks for this gem, it's great and we've been using it for quite a while. Unfortunately, 37Signals new auth system breaks the latest version of tinder.

Also, the gem is not erroring even though it can no longer log in. It will return true after you log in, but if you investigate what page hpricot is trying to use, it's a redirect-to-login page.

For more info on the change:
http://37signals.com/accounts

Thanks,
Matt

or need also other parameters? doesn't get the account banned if missing some parameters?

I was trying to use the campfire-bot, which uses tinder to actually talk to campfire. It was hanging. I was able to track things down to a command in tinder that hangs forever. I'm running OSX Snow Leopard, an rvm build of 1.8.7, and bundler. From an irb session, I was able to connect to campfire, get a room, speak, but when I run room.listen it hangs indefinitely.

ruby-1.8.7-p302 > require 'tinder'  
=> true 
ruby-1.8.7-p302 > campfire = Tinder::Campfire.new 'xxx', :token => 'yyy'
 => #<Tinder::Campfire:0x1022e00b0 ... >
ruby-1.8.7-p302 > room = campfire.rooms.first 
warning: peer certificate won't be verified in this SSL session
 => #<Tinder::Room:0x1022a2e68 @name="2nd place" ... >
ruby-1.8.7-p302 > room.speak "NOW"
warning: peer certificate won't be verified in this SSL session
 => {"message"=>{"room_id"=>363979, "created_at"=>"2011/05/02 22:39:33 +0000", "body"=>"NOW", "id"=>345280984,  "type"=>"TextMessage", "user_id"=>900697}} 
ruby-1.8.7-p302 > room.listen(:timeout => 8) do |x|
ruby-1.8.7-p302 >
ruby-1.8.7-p302 >     puts "Listening #{x.inspect}"
ruby-1.8.7-p302 ?>  end
#hangs forever here

Hi,
I got some errors while trying to get Campfire notifications going in CI Joe & decided to go digging.
I was initially getting the ActiveSupport 2.3 issue (#24), but got around by installing 3.x
Things now seem to break when CI Joe calls Tinder::Campfire.find_room_by_name().

I went through with irb & seem to get an error whenever I call anything to do with room.

$ irb -rubygems

require 'tinder'
t = Tinder::Campfire.new('my_subdomain', :token => "my_token", :ssl => false)
t.find_room_by_name("my_room")
NoMethodError: undefined method []' for nil:NilClass from /usr/lib/ruby/gems/1.8/gems/tinder-1.7.0/lib/tinder/campfire.rb:34:inrooms'
from /usr/lib/ruby/gems/1.8/gems/tinder-1.7.0/lib/tinder/campfire.rb:46:in `find_room_by_name'
from (irb):4

t.rooms
NoMethodError: undefined method []' for nil:NilClass from /usr/lib/ruby/gems/1.8/gems/tinder-1.7.0/lib/tinder/campfire.rb:34:inrooms'
from (rib):5

I have things running on Ubuntu 11.04 server, ruby 1.8.7, rubygems 1.3.7
tinder 1.7.0, activesupport 3.1.0, cijoe 0.9.2, faraday 0.7.4, faraday_middleware 0.7.0

any ideas?