greptilian logo

IRC log for #rest, 2014-06-03

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

Time S Nick Message
00:21 jzsprague joined #rest
00:21 ldiamond joined #rest
00:59 wavded joined #rest
01:12 wavded joined #rest
02:16 Left_Turn joined #rest
02:16 ldiamond joined #rest
03:12 fumanchu_ joined #rest
03:18 fumanchu joined #rest
04:50 wilmoore joined #rest
05:24 adaro joined #rest
06:20 rosstuck joined #rest
06:48 adaro joined #rest
06:59 _ollie joined #rest
07:33 interop_madness joined #rest
07:59 jzsprague joined #rest
08:09 graste joined #rest
08:20 Left_Turn joined #rest
08:49 martinfilliau joined #rest
08:53 rincewind joined #rest
09:41 shrink0r joined #rest
10:01 dEPy joined #rest
11:30 _ollie joined #rest
12:04 m0ltar joined #rest
12:36 ldiamond joined #rest
12:43 fumanchu_ joined #rest
12:44 charlex joined #rest
13:22 seantallen joined #rest
13:56 _ollie joined #rest
14:39 wavded joined #rest
15:02 shrink0r joined #rest
15:08 nkoza joined #rest
15:10 wavded_ joined #rest
15:27 wilmoore joined #rest
15:29 wavded joined #rest
15:49 _ollie joined #rest
16:03 _ollie joined #rest
16:19 whartung joined #rest
17:06 charlex joined #rest
17:32 pdurbin hmm, if I'm letting people send an API key/token to hit an API endpoint... I guess I should just always require SSL... because I can't predict when someone will try to send a key versus when they'll try an unauthenticated (search) request. safer to just always require SSL.
17:53 whartung_ joined #rest
18:24 ph88_ joined #rest
18:45 charlex joined #rest
19:26 P3nnyw1se joined #rest
19:26 P3nnyw1se I dont suppose getting help understanding enterprise integration patterns ... that this is the rightplace to come ? :D
19:29 trygvis as long as they're REST related they're welcome
19:29 trygvis if they are about RPC over HTTP, not so much
19:30 P3nnyw1se oh shit :P .. well I kinda thing this is more general
19:30 P3nnyw1se I'm having an issue understanding the concept of Event Driven Consumer pattern.. and it just seems so basic so I don't know what I'm missing
19:33 pdurbin what are you missing?
19:35 P3nnyw1se I read this text: This is also known as an asynchronous receiver, because the receiver does not have a running thread until a callback thread delivers a message. We call it an Event-Driven Consumer because the receiver acts like the message delivery is an event that triggers the receiver into action
19:35 P3nnyw1se this confuses me, isn't the callback thread a running thread then? ..
19:38 fumanchu_ yes, but it's owned and operated by the message queue component, not the receiver component
19:39 P3nnyw1se so.. its about having an application seperate from the actualy application? one that just handles message? .. and will work and handle the messages no matter what the actualy application is doing?
19:40 graste joined #rest
19:41 fumanchu yes and no. it's better to not overload the word "application". Instead, you have a main event loop (that is called different things in different frameworks. Python's Twisted framework for example calls it a "reactor"), and then you add functionality by registering callbacks
19:42 P3nnyw1se but what about the message service, someone must be just waiting ? who is running the loop, the network card ?
19:43 fumanchu in a single-process arch, it's typically the main thread
19:43 fumanchu in multi-process, you have a master process that routes messages/events
19:44 fumanchu (or even multiple ones as a load balancer)
19:45 fumanchu that text you pasted above can be a little misleading
19:45 fumanchu often, the consumers are written as a thread that is blocked on a select() call until they receive a message
19:45 fumanchu so technically, they do have a running thread
19:46 P3nnyw1se ah thx this is making me understand it a bit more, gotta read up on callbacks I see to fully get it
19:47 fumanchu the patterns book is at that ideal level of abstraction where you can't understand a single paragraph in it until you've built at least one of every style mentioned in it :(
19:48 P3nnyw1se yeah the thing is I keep googling this pattern and its just the one line...
19:48 P3nnyw1se which is frustrating cause then it seems to me like I should get it
19:49 SandroSantos joined #rest
19:50 SandroSantos Guys, I need to make a login, in my application, with my email + password... this is a RPC, right?
19:50 fumanchu you'll learn 100x more quickly by writing a simple multiprocess server where the children select() on a pipe and then go do their thing when they receive a message than gazing at UML all day
19:51 fumanchu P3nnyw1se: take a quick trip through, say, a ZeroMQ tutorial and the UML will seem academic and pedantic
19:52 P3nnyw1se seems fair to get handson... it would basicly be creating a service that handles incoming messages, and invoke a method in the 'main loop/app' ?
19:52 fumanchu yup
19:53 P3nnyw1se and I see a lot about callback.. this means that I would pass the method as an arguement?
19:55 fumanchu typically, the "receiver" subscribes to the message channel by adding itself (or one of its endpoints, if more than one) as a callback to the publisher
19:55 fumanchu engine.subscribe("event1", self)
19:56 fumanchu then when some other code calls engine.publish("event1"), the engine calls/sends a message to that "self" callback
19:56 fumanchu engine.subscribe("event1", thing1.foo)
19:57 fumanchu then inside engine.publish, there would be a call to thing1.foo('event1', *args)
19:57 fumanchu (pub/sub is not the only model that can be built on event-driven consumers. it's *really* abstract)
19:59 fumanchu again, I'd recommend you read e.g. the ZeroMQ Guide. it will give a concrete basis for understanding the very abstract EIP book
20:00 P3nnyw1se where can i find that guide? my googl looks crazy when I attempt it with that
20:00 fumanchu http://zguide.zeromq.org/page:all
20:01 fumanchu there are links at the top for the same guide but with examples in Python, Lua, PHP, etc
20:01 P3nnyw1se oh its long :P and probably hard .. I need to take some time I see
20:02 saml SandroSantos, no
20:02 saml POST /session ?
20:04 SandroSantos saml: so, I will call a resource user?email=blablabla@teste.com&pass=123456 ?
20:08 saml no
20:08 saml SandroSantos,   /session
20:09 saml when you want to login,  <form action="/session" method="POST"><input name="email"><input name="pass">
20:10 SandroSantos thanks, saml... I got it!
20:10 m0ltar joined #rest
20:11 SandroSantos so, session will be a resource? (sorry, I am newbie)
20:18 saml SandroSantos, yes
20:18 saml POST /session   will create /session/1
20:18 saml logging out will be... DELETE /session/1  maybe
20:20 SandroSantos great! thank you, saml !
21:29 charlie_ joined #rest
21:41 m0ltar joined #rest
21:54 m0ltar joined #rest
21:57 P3nnyw1se so is an event driven consumer, the same in reality as an event handler `?
21:58 talios joined #rest
22:07 fumanchu basically yes. the only distinction you might draw is that a "handler" might be part of a larger "consumer" component.
22:07 fumanchu but if there's only one, it's easy to use one as a synechdoche for the other
22:22 P3nnyw1se talking about more consumer components
22:22 P3nnyw1se http://www.eaipatterns.com/CompetingConsumers.html  <-----   ---->   http://www.eaipatterns.com/MessageDispatcher.html             Message dispatcher is just for ordering the way consumers/performers recieves messages?
22:28 charlex joined #rest
22:47 danfinch joined #rest
23:15 asdf`_ joined #rest

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.