| 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 |
