00:07:11  * mdedetrichquit (Quit: Computer has gone to sleep.)
00:08:20  * mdedetrichjoined
01:03:17  * mdedetrichquit (Quit: Computer has gone to sleep.)
01:23:27  * colinsullivanquit (Quit: Leaving.)
01:28:52  * mdedetrichjoined
01:52:46  * wamattquit (Quit: wamatt)
01:53:12  * wamattjoined
02:23:30  * mdedetrichquit (Quit: Computer has gone to sleep.)
02:27:54  * mdedetrichjoined
03:20:36  * andrewreedyjoined
03:21:06  <andrewreedy>Hey, is .4 in active dev
05:22:58  * ArxPoeticaquit (Quit: Leaving.)
05:29:56  * lluadquit (Quit: lluad)
05:56:40  * aus3ysjoined
05:59:48  * colinsullivanjoined
06:27:58  * dennisma_quit (Remote host closed the connection)
06:28:33  * dennismartenssonjoined
06:32:38  * dennismartenssonquit (Ping timeout: 240 seconds)
07:23:11  * colinsullivanquit (Quit: Leaving.)
07:29:52  * mdedetrichquit (Quit: Computer has gone to sleep.)
07:30:40  * colinsullivanjoined
07:31:34  * colinsullivanquit (Client Quit)
07:36:10  * mdedetrichjoined
07:38:34  * mdedetrichquit (Client Quit)
07:39:48  * mdedetrichjoined
07:53:30  * mdedetrichquit (Ping timeout: 264 seconds)
08:02:47  * andrewreedyquit (Ping timeout: 250 seconds)
08:29:28  <freezy3k>is there a way to pass a variable to the jade template when rendering?
08:29:53  * k1iquit (Ping timeout: 240 seconds)
08:29:59  * k1ijoined
08:38:26  * mdedetrichjoined
08:39:34  * mdedetrichquit (Remote host closed the connection)
09:44:58  * wamattquit (Quit: wamatt)
10:03:50  * daslichtjoined
10:04:04  <daslicht>hello all
10:04:29  <daslicht>according to the description on Git, Socketstream is exactly for me
10:17:21  * aus3ysquit (Quit: Leaving...)
10:45:59  * aus3ysjoined
10:46:27  <aus3ys>daslicht, do you know about sailsjs?
10:46:40  <daslicht>nope
10:47:01  <daslicht>essentiallt i am looking for the holy grail :)
10:47:25  <daslicht>I like to create a reactive js apploication which can be fully indexed
10:47:48  <daslicht>where it degrades gracefully without things like phantomjs
10:48:05  <daslicht>essentially something like derby but more modular and better documented
10:48:34  <daslicht>i look now for sails
10:49:24  <daslicht>do you use saiuls ?
10:49:27  <daslicht>sails
10:53:20  * vguerrajoined
10:55:39  * mdedetrichjoined
10:57:52  <daslicht>ok sails js is not indexable , or indexed thats why i dont know it lol
10:58:54  <daslicht>nor does it provide html snapshots
10:58:55  <daslicht>http://sailsjs.org/?_escaped_fragment_=/
11:07:18  * mdedetrichquit (Ping timeout: 264 seconds)
11:14:16  <daslicht>aus3ys: thanks , looks good, reading the docs now
11:15:02  * mdedetrichjoined
11:16:45  * mdedetrichquit (Client Quit)
11:17:26  * aus3ysquit (Ping timeout: 240 seconds)
11:18:17  * mdedetrichjoined
11:18:32  * aus3ysjoined
11:19:03  <aus3ys>daslicht, np... I started with ss aswell, but then switched...
11:19:17  <daslicht>heh
11:19:22  <daslicht>you are now into sials ?
11:19:26  <daslicht>sails
11:20:02  <aus3ys>yes... few days back sails received mayor update, a lot more features and stuff
11:20:10  <daslicht>cool
11:20:22  <daslicht>how is teh community ?
11:20:51  <aus3ys>cool... there's a node.js studio behind sailsjs and they are amazing... checkout github issues, active aswell
11:21:03  <daslicht>nice
11:22:02  <aus3ys>personally i think that sailsjs is the future of web apps... very easy... basic web api is the boilerprate for models/controllers... works with socket, http requests...
11:25:02  * mdedetrichquit (Ping timeout: 240 seconds)
11:32:38  * mdedetrichjoined
11:47:38  * mdedetrichquit (Quit: Computer has gone to sleep.)
11:51:34  * mdedetrichjoined
12:34:32  * mdedetrichquit (Quit: Computer has gone to sleep.)
12:37:10  * aus3ysquit (Quit: Linkinus - http://linkinus.com)
13:44:47  * ArxPoeticajoined
13:50:43  * ArxPoeticaquit (Quit: Leaving.)
14:05:11  <freezy3k>hmm, any way to check if server is ready?
14:05:21  <freezy3k>there is ss.server.on('ready', ...)
14:06:08  <freezy3k>but i'd need to check this in a controller, where the event was potentially alreay emitted
14:07:43  * daslichtquit (Remote host closed the connection)
14:10:14  * aus3ysjoined
14:40:47  * daslichtjoined
14:51:37  * ArxPoeticajoined
15:15:46  * aus3ysquit (Quit: Leaving...)
15:43:39  * sonofjackquit (Remote host closed the connection)
15:49:34  * sonofjackjoined
15:59:57  * vguerraquit (Remote host closed the connection)
16:34:58  * dennismartenssonjoined
16:46:09  * lluadjoined
17:14:36  * dennismartenssonquit (Remote host closed the connection)
17:29:39  * dennismartenssonjoined
18:29:20  <k1i>daslicht: derbyjs
18:50:51  * dennismartenssonquit (Remote host closed the connection)
19:40:03  * wamattjoined
20:12:22  <ArxPoetica>hey k1i can I ask your opinion about something?
20:20:52  <freezy3k>ArxPoetica now you're there, need your opinion on something too
20:21:20  <ArxPoetica>hey freezy3k
20:22:12  <freezy3k>i have multiple pages, on which i do stuff with js. now typically, a page can "process" something, in which case an event is emitted and the js greys stuff out.
20:22:35  <freezy3k>but when the page opens up when it's already processing the event has already passed
20:22:52  <freezy3k>so i would need to separately check if processing on or not
20:23:21  <freezy3k>which is kind of cumbersome - also the fact that i need to check everytime if the socket is up or not is painful
20:23:45  <freezy3k>what are the best practices around these kind of problems?
20:24:31  * sonofjackquit (Remote host closed the connection)
20:27:29  * sonofjackjoined
20:29:35  <ArxPoetica>tell me what you mean by "check"? what process are you talking about?
20:29:45  <ArxPoetica>Is this related to routing?
20:30:04  <freezy3k>well
20:30:26  <freezy3k>multiple pages is irrelevant, actually
20:30:31  <freezy3k>let's say i have just one page
20:30:39  <freezy3k>with one button
20:30:50  <ArxPoetica>so no pushstate, in other words. ok
20:31:05  <freezy3k>when you click on it, it starts some "processing", then ends. while processing, it's grey
20:31:24  <freezy3k>so when processing starts via rpc, the server sends an event so the clients can grey out the button.
20:31:51  <freezy3k>but what if a client arrives when processing has started?
20:31:56  <ArxPoetica>so you mean its greyed out *AFTER* the rpc returns?
20:31:58  <ArxPoetica>responds
20:32:12  <freezy3k>the rpc just starts processing
20:32:18  <freezy3k>and sends an event when done
20:32:28  <freezy3k>(and when started)
20:32:35  <ArxPoetica>I don't understand the order of events.
20:32:42  <freezy3k>ok
20:32:43  <ArxPoetica>why would it be greyed out DURING?
20:32:54  <ArxPoetica>(it's grayed to me, ha)
20:32:56  <freezy3k>events are:
20:33:01  <freezy3k>1. mouse click on button
20:33:15  <freezy3k>2. client sends rpc says "start processing"
20:33:25  <ArxPoetica>yup
20:33:25  <freezy3k>3. server sends event to clients so they grey out the button
20:33:30  <ArxPoetica>right
20:33:31  <freezy3k>4. processing finishes
20:33:31  <ArxPoetica>ok
20:33:42  <freezy3k>4. server sends "event finished" so clients can ungrey
20:33:44  <ArxPoetica>shouldn't 3 and 4 be swapped?
20:33:49  <freezy3k>uh, 4 ->5
20:34:02  <freezy3k>no, the processing is repeatable
20:34:10  <ArxPoetica>wait, so you have TWO responses from one rpc call?
20:34:17  <ArxPoetica>that doesn't make sense to me
20:34:17  <freezy3k>just DURING the event no additional processing should be started
20:34:46  <freezy3k>the rpc call doesn't return anything directly,
20:34:51  <freezy3k>but yes, 2 events will be sent
20:34:55  <ArxPoetica>so in other words, the button is gray DURING the processing
20:34:58  <freezy3k>exactly.
20:35:05  <ArxPoetica>but don't RPCs only send ONE response?
20:35:17  <ArxPoetica>(tbh, I've never tried more than one response)
20:35:25  <ArxPoetica>isn't it just a round trip?
20:35:28  <freezy3k>yes it is
20:35:37  <ArxPoetica>so your scenario doesn't make sense
20:35:38  <freezy3k>the rpc call doesn't return anything
20:35:43  <k1i>ArxPoetica: hi
20:35:46  <k1i>just missed your ping
20:35:48  <ArxPoetica>hey k1i
20:35:54  <ArxPoetica>I'll try and double task here
20:35:56  <ArxPoetica>ha
20:36:05  <freezy3k>the server sends 2 events, started and completed
20:36:32  <ArxPoetica>well. you've sent an event to the server telling it to start — but that's from the CLIENT.
20:36:36  <freezy3k>it's not an rpc response but an event. because with an rpc reponse, only the client calling would get it
20:36:52  <ArxPoetica>I'm very confused by this.
20:36:56  <ArxPoetica>(obviously, ha ha)
20:37:05  <freezy3k>yeah i figure ;)
20:37:20  <freezy3k>imagine you have multiple clients
20:37:23  <ArxPoetica>what exactly do you mean by "event"?
20:37:38  <freezy3k>when one presses the button, it should grey on all clients
20:38:01  <freezy3k>an event: ss.publish.all('foo', 'bar')
20:38:10  <ArxPoetica>AHHHHH
20:38:11  <ArxPoetica>ok
20:38:21  <ArxPoetica>that's not really an event though
20:38:22  <ArxPoetica>ha
20:38:39  <ArxPoetica>but I'm with you now.
20:38:52  <ArxPoetica>You're saying the client is listening for that…got it
20:38:56  <freezy3k>https://github.com/socketstream/socketstream/blob/master/doc/guide/en/pub_sub_events.md
20:38:59  <freezy3k>pub sub events :p
20:39:00  <ArxPoetica>the event is on the client end
20:39:04  <ArxPoetica>with you now
20:39:13  <ArxPoetica>so is this a question about latency?
20:39:18  <freezy3k>no
20:39:20  <ArxPoetica>k
20:39:25  <freezy3k>it's about the status
20:39:45  <freezy3k>so if all clients are connected all the time, everybody gets all the events and everybody is happy
20:40:01  <ArxPoetica>sure
20:40:05  <freezy3k>but if a client connects when processing has already started
20:40:15  <freezy3k>it missed the "started" event, right?
20:40:31  <ArxPoetica>um—that depends
20:40:41  <freezy3k>a new browser opening
20:40:45  <ArxPoetica>and, yes, strictly speaking, it is up to you to keep track of that "event"
20:40:49  <freezy3k>which never accessed the site
20:40:49  <ArxPoetica>or pubsub message
20:40:57  <ArxPoetica>in that specific instance
20:41:30  <freezy3k>what i'm saying is that when loading that page, the client has no idea about the status of the processing
20:41:40  <freezy3k>so that status has to be transferred separately
20:41:58  <ArxPoetica>sort of, yes
20:42:20  <freezy3k>so when implementing this, i always have to do it twice: 1. logic for arriving events and 2. for initial status
20:42:20  <ArxPoetica>I mean—that depends on what the "process" is
20:42:30  <ArxPoetica>yes, that's correct
20:43:02  <ArxPoetica>though a well designed app would consolidate that type of functionality, i.e., keep it DRY
20:43:05  <freezy3k>..which is cumbersome, hence the question if there were better practices or shortcuts or whatever available that facilitates this kind of pattern
20:43:14  <ArxPoetica>ok I'm with you
20:43:15  <freezy3k>meaning?
20:43:23  <ArxPoetica>dry=don't repeat yourself
20:43:53  <ArxPoetica>often translates to something modular and well built functionally
20:44:06  <freezy3k>well, the "action" is obviously in a function, what has to be done twice is the wiring up
20:44:49  <freezy3k>(replace "action" by "logic")
20:45:15  <ArxPoetica>alternatively, you can use channels
20:45:53  <freezy3k>req.session.channel...?
20:46:53  <ArxPoetica>just a sec
20:47:26  <ArxPoetica>sorry back
20:48:04  <ArxPoetica>so basically, you have to keep track of everything on the server—if you're doing something on the client you have to match it on the server
20:48:30  <ArxPoetica>I think that channels bit was actually a red herring, ha
20:48:45  <ArxPoetica>and vice versa
20:48:53  <ArxPoetica>so
20:48:57  <ArxPoetica>click the button
20:50:13  <ArxPoetica>*before* you send out the ss.publish.all or the equivalent channel subscription, you need to store the information about the process
20:50:24  <ArxPoetica>some truthy property "hey, I'm running" "true!"
20:50:47  <freezy3k>yeah
20:50:48  <ArxPoetica>so when a new user checks in, that user can ping the server and find out the truthy (or falsey) state
20:51:09  <freezy3k>sure
20:51:13  <ArxPoetica>ha ok
20:51:20  <freezy3k>as i said, cumbersome ;)
20:52:03  <ArxPoetica>well…sort of. it doesn't have to be. like I said, if you engineer it well, (create DRY functionality) those checks can be simpler
20:52:14  <freezy3k>an easy approach would be to use ss-angular's model feature, which polls anything from the server, meaning i just define $scope.status and behind it gets updated automatically
20:52:29  <freezy3k>but that means polling, which i dont like
20:52:58  <ArxPoetica>ah. now you're talking about stuff I just wouldn't know. but yes, polling is a step backward.
20:53:28  <freezy3k>well, you're the realtime experts, i've started like 3 days ago ;)
20:53:57  <ArxPoetica>ha ha
20:54:08  <ArxPoetica>i only pretend to be an expert ;)
20:54:18  <freezy3k>np :)
20:54:21  <freezy3k>other question
20:54:25  <freezy3k>while talking about events
20:54:25  <ArxPoetica>sure
20:54:26  <freezy3k>https://github.com/socketstream/socketstream/blob/master/doc/guide/en/pub_sub_events.md
20:54:41  <freezy3k>"sending to private channels"
20:54:51  <freezy3k>req.session.channel.subscribe('disney')
20:54:58  <ArxPoetica>yes
20:55:03  <freezy3k>why does the server have to subscribe to the channel?
20:55:10  <freezy3k>we're on server side here, right?
20:55:21  <freezy3k>and there's no example of how a client would subscribe to a channel
20:55:29  <ArxPoetica>right
20:55:37  <ArxPoetica>well. sort of, ha.
20:55:44  <ArxPoetica>the server is keeping track of all the clients
20:55:59  <ArxPoetica>a "channel" of clients connected by the server
20:56:41  <freezy3k>so the "subscription" is done on server side?
20:57:22  <freezy3k>and if a client wants to subscribe to a channel, i have to figure out myself how the client tells the server to subscribe?
20:58:03  <ArxPoetica>well, you have the luxury of setting that logic, yes
20:58:18  <freezy3k>hehe ok
20:58:20  <ArxPoetica>but it's ultimately the server making the decision
20:58:27  <ArxPoetica>the client might tell it what it wants
20:58:32  <ArxPoetica>but the logic will be on the server
20:58:40  <freezy3k>ok
20:58:58  <ArxPoetica>if(disney) { req.session.channel.subscribe('disney'); }
21:00:05  <ArxPoetica>this requires you use sessions, naturally
21:00:05  <ArxPoetica>req.use('session');
21:00:07  <freezy3k>yeah, only that "disney" needs to come from somewhere ;)
21:00:14  <ArxPoetica>in the server RPC file
21:00:34  <ArxPoetica>right—typically the client making the request in the rpc
21:00:46  <freezy3k>yeah i'll see how i'll handle that
21:01:35  <freezy3k>i actually wanted to use channels more like a filtering mechanism so a client doesn't get spammed with events it doesn't deal with because he's not the page that deals with it
21:02:30  <freezy3k>i'll probably end up with an "admin" channel only then
21:02:38  <ArxPoetica>right
21:02:59  <ArxPoetica>I'm actually trying to figure out some admin related stuff myself right now
21:03:22  <ArxPoetica>not using angular—I'm kind of a DIY guy (not to be confused w/ DRY, ha)
21:04:05  <freezy3k>depending on what you're doing that will surely work
21:04:24  * dennismartenssonjoined
21:04:49  <freezy3k>there's just one thing i very dislike in ss - but i suppose that's a general "one page site" problem. everything gets loaded. basically users see my whole admin section
21:04:58  <freezy3k>without any data, granted, but still.
21:05:11  <ArxPoetica>it's a general problem, yes
21:05:15  <freezy3k>well, they don't "see" it, but they get all the html and js code for it
21:05:20  <ArxPoetica>right
21:05:33  <ArxPoetica>that's actually the exact problem I'm working on right now
21:06:01  <freezy3k>let me know if you figure out something. i've read that "post loading" code is somehow possible, but seemed complicated
21:06:20  <ArxPoetica>well, that IS the alternative way—but it's not built into ss
21:06:38  <ArxPoetica>but you can do it through an rpc call
21:06:53  <ArxPoetica>or some other mechanism—
21:07:26  <freezy3k>i have no clue how the loading works, that's still one big magic box for me
21:07:39  <ArxPoetica>https://github.com/socketstream/socketstream/blob/master/doc/guide/en/writing_request_responders.md
21:08:00  <ArxPoetica>you could, for example, write your own request handler
21:08:00  <freezy3k>Writing Request Responders is going to become a lot easier in SocketStream 0.4.
21:08:12  <ArxPoetica>purportedly :)
21:08:13  <freezy3k>haha, now you need to decide where you put your effort ;)
21:08:23  <ArxPoetica>I don't think I'll do this.
21:08:37  <ArxPoetica>This is for a client, and they don't have a high bar
21:08:53  <ArxPoetica>but it is a problem
21:09:01  <ArxPoetica>I'm using pushstate for routing
21:09:14  <ArxPoetica>and if it's an admin-based route, it shouldn't dish the content
21:09:30  <ArxPoetica>which is what I wanted to ask you k1i
21:09:54  <freezy3k>yeah i'll need to do the same thing
21:09:54  <ArxPoetica>if you think, with realtime apps, when you're doing admin-based routing if the page should be completely refreshed
21:10:20  <ArxPoetica>or if I just check with RPC calls EVERY TIME on /admin/:whatever
21:11:01  <freezy3k>well, in RPC you have the user object via the session and you can easily check whether it's an admin, right?
21:11:08  <ArxPoetica>right
21:11:15  <freezy3k>since RPC calls are not really route-based
21:11:28  <freezy3k>but on client side you'll also have to hide stuff
21:11:30  <ArxPoetica>but for comparison
21:11:44  <ArxPoetica>in traditional HTTP apps, EACH ROUTE checks the session on the server
21:11:57  <ArxPoetica>so do I do the same, for pushstate routing? but with RPC?
21:12:02  <ArxPoetica>each route?
21:12:10  <ArxPoetica>cause that's a lot of RPC for routing :)
21:12:32  <ArxPoetica>but then again, that's a lot of HTTP for traditional routing :P
21:12:35  <ArxPoetica>follow me?
21:12:38  <freezy3k>well in angular i would just have an admin flag in the root scope and hide stuff via ng-show
21:13:07  <ArxPoetica>I s'pose thats true
21:13:14  <ArxPoetica>that's the easier solution
21:13:15  <freezy3k>but in whatever JS, you can save the admin state and render your template accoringly
21:13:40  <ArxPoetica>basically, anything that requires an RPC can still check the role/state of the user anyway
21:13:42  <ArxPoetica>so that works
21:14:04  <freezy3k>well forbidding the user type the "admin url" would be silly since he has access to it anyway.
21:14:12  <k1i>reading
21:14:25  <ArxPoetica>but you're right—it IS still a problem with realtime apps to have ALL the HTML available
21:14:28  <freezy3k>important is that rpc knows who's admin and who's not and refuses calls if not
21:14:32  <k1i>I highly suggest you check out Derby, ArxPoetica.
21:14:37  <ArxPoetica>lol
21:14:50  <k1i>the routing was very, very well-thought out
21:14:52  <ArxPoetica>has it gotten better? I feel like we've had this conversation
21:14:55  <k1i>yes
21:14:58  <k1i>significantly
21:15:06  <ArxPoetica>Meteor has gotten better too.
21:15:10  <k1i>SS fills a very specific niche: the SPA
21:15:21  <ArxPoetica>Unfortunately, I'm tied to SS for this project, so it's too late.
21:15:25  <k1i>meteor hasnt had a major (technically minor) version release in like 2 months i think
21:15:26  <k1i>ah
21:15:34  <ArxPoetica>It's been in production for over 8 months, and I'm being tacked on to the end of it.
21:15:38  <k1i>hollow?
21:15:41  <ArxPoetica>no
21:15:46  <k1i>SS .3?
21:15:50  <freezy3k>k1i what's SPA?
21:15:51  <ArxPoetica>yup
21:15:57  <ArxPoetica>hold on I'll get the link
21:16:12  <k1i>single apge app
21:16:23  <freezy3k>ah
21:16:26  <freezy3k>k
21:16:28  <ArxPoetica>https://github.com/engagementgamelab/CivicSeed
21:16:42  <k1i>routing is a very complicated aspect of realtime apps
21:16:47  <k1i>especially in relation to templating
21:16:57  <ArxPoetica>I've been using Davis.js — works okay
21:17:08  * dennismartenssonquit (Read error: Connection reset by peer)
21:17:14  <ArxPoetica>but yeah— if you want super sophisticated admin protection, it's a problem all right
21:17:27  * dennismartenssonjoined
21:17:30  <k1i>so
21:17:38  <k1i>you dont want non-admins to have the code downloaded?
21:17:59  <ArxPoetica>and what is SPA?
21:18:06  <k1i>single page app
21:18:18  <ArxPoetica>Fortunately, I'm not hugely concerned with admins seeing HTML
21:18:29  <ArxPoetica>it's more important that they can't do certain things on the server.
21:18:47  <k1i>so
21:19:00  <ArxPoetica>Also, the use case for this app doesn't require huge security needs
21:19:02  <k1i>check the currently logged in user model for an admin flag?
21:19:08  <ArxPoetica>yeah
21:19:09  <k1i>on RPC
21:19:10  <ArxPoetica>right
21:19:15  <ArxPoetica>already doing that :)
21:19:25  <ArxPoetica>but I'm hired on to clean up some of the coding
21:19:31  <ArxPoetica>routing included
21:19:34  <ArxPoetica>and to add tests
21:19:37  <ArxPoetica>etc.
21:20:14  <k1i>where is it dirtiest
21:20:23  * mikljoined
21:20:33  <ArxPoetica>so it looks like they've been active again https://github.com/codeparty/derby
21:20:35  <ArxPoetica>which is good
21:20:42  <k1i>the more important stuff IMO is located @
21:20:50  <k1i>https://github.com/codeparty/racer
21:20:57  <k1i>the bulk of the heavy lifting and important stuff is there
21:21:10  <ArxPoetica>have you made any derby apps?
21:21:17  <k1i>nothing production
21:21:20  <k1i>plenty of hello-worlds/tests
21:21:28  <k1i>i am waiting for a few very specific features that I've discussed here..
21:21:35  * dennismartenssonquit (Read error: Operation timed out)
21:21:35  <k1i>https://github.com/codeparty/racer/issues/131
21:22:02  * dennismartenssonjoined
21:22:04  <ArxPoetica>https://github.com/meteor/meteor <— it's pretty active
21:22:06  <ArxPoetica>fyi
21:22:26  <k1i>ydah
21:22:42  <ArxPoetica>ydah? what's that?
21:22:43  <ArxPoetica>ha
21:22:44  <k1i>yeah
21:22:46  <k1i>I am keeping an eye on them
21:22:47  <ArxPoetica>lol
21:22:50  <ArxPoetica>right
21:22:55  <ArxPoetica>how's your project coming btw?
21:22:56  <k1i>but I feel like the dev team has the wrong priorities in mind
21:23:09  <k1i>stalled; been doing consulting/looking for long-term consulting stuff
21:23:52  <k1i>meteor for instance has no concept of a "page" or "router", they force their user authentication system on you, and the dev team spends a tremendous amount of time appealing to the lowest-common denominator by developing their 'smart packages' (rather than using the existing NPM standard)
21:24:28  <freezy3k>really?
21:24:37  <k1i>no OT (not really a bad thing), no server-side rendering concept in place (mostly due to a lack of router), and a very strange idea on scaling
21:24:44  <freezy3k>Seven Principles of Meteor: [...] Embrace the Ecosystem. Meteor is open source and integrates, rather than replaces, existing open source tools and frameworks.
21:24:45  <ArxPoetica>k1i — and Derby doesn't force ???
21:24:46  <ArxPoetica>ha
21:25:03  <k1i>Derby doesn't give you anything beyond a userID
21:25:11  <k1i>and that's removable middleware
21:25:17  <k1i>its a much more modular (node-like) framework
21:25:21  <ArxPoetica>i see
21:25:30  <ArxPoetica>so you COULD replace parts if you like
21:25:31  <k1i>it's built on Express, so anything you want to do with Express is very easily implementable
21:25:32  <k1i>yes
21:25:43  <ArxPoetica>I just remember the first time I took a look at it being totally frustrated
21:25:44  <ArxPoetica>ha
21:25:52  <k1i>the documentation has gotten much, much better
21:25:54  <ArxPoetica>but that was eons ago in computer years
21:26:03  <ArxPoetica>it wasn't the documenation
21:26:07  <k1i>Racer is the real treat, it has been rewritten entirely and the codebase looks really solid
21:26:07  <ArxPoetica>it was the setup
21:26:17  <ArxPoetica>but I'll take your word for it
21:26:29  <k1i>1) install node/npm 2) install mongodb 3) install redis 4) derby create 5) npm start
21:26:46  <ArxPoetica>I need to start cracking on documention for socketstream
21:26:59  <ArxPoetica>I know ownb__ wants to focus elsewhere, but FOR ME that crucial
21:27:04  <k1i>you should implement racer into SS
21:27:05  <ArxPoetica>*critical
21:27:45  <ArxPoetica>owen wants to use this: https://github.com/socketstream/realtime-transport
21:28:00  <k1i>heh, racer is the model framework
21:28:14  <ArxPoetica>sorry, I mean this: https://github.com/3rd-Eden/primus
21:29:11  <ArxPoetica>obviously I need to do a little reading up on it
21:29:20  <ArxPoetica>because I don't 100% understand these components
21:29:21  <k1i>heh, so many abstraction layers now for WS/longpoll/etc.
21:29:41  <ArxPoetica>it does feel a little stretched, yes
21:30:23  <k1i>Derby is the routing (exposed from express), view layer (server side rendering), and glue to Express; Racer is a realtime model system that mirrors queries, subscriptions, and models in both the client and server
21:31:23  <ArxPoetica>gotcha
21:31:31  <ArxPoetica>so meteor-esque in that regard
21:31:33  <k1i>Racer implements something like Primus
21:31:35  * paulbjensenjoined
21:31:44  <k1i>an abstraction layer for WS/browserhcannel/socket.io/engine.io
21:31:53  <k1i>racer uses browserchannel by default
21:32:40  <k1i>Meteor's primary advantages are 1) DDP (being a formalized spec) 2) funding
21:32:51  <ArxPoetica>funding, yes, ha
21:32:52  <k1i>but the project is very poorly managed IMO.
21:33:21  <ArxPoetica>well, they definitely made some pooooor decisions early on, only fixed by community outcry
21:33:28  <k1i>still not fixed, heh
21:33:39  <k1i>they added stop-gap measures to allow npm package integration but it is really weird and poorly-done
21:34:05  <ArxPoetica>my main problem with Derby is that it's still too out of the box. this is probably my problem, but I want a little more DIY. but maybe that really is a problem :)
21:34:17  <k1i>well its Express, that's about as bare as it gets
21:34:19  <ArxPoetica>also, I just need to get off my but and help owenb out a little more by actually coding
21:34:38  <k1i>im not sure which part you want to DIY, heh
21:34:47  <ArxPoetica>models
21:34:49  <ArxPoetica>routin
21:34:52  <ArxPoetica>*routing
21:35:01  <k1i>express's routing is pretty standardized
21:35:02  <ArxPoetica>I think what I mean is more operability
21:35:15  <ArxPoetica>I don't want to always use express, tho' ;)
21:35:17  <k1i>and the model system isn't even a game I'd want to play after seeing Racer/ShareJS ;)
21:35:19  <ArxPoetica>again—maybe this is my problem
21:35:29  <ArxPoetica>but you may be right
21:35:33  <k1i>very, very well maintained and tested codebase
21:35:40  <ArxPoetica>time will tell, I think—the race is still on imho
21:35:40  <k1i>with everything very well-thought-out initially
21:35:52  <ArxPoetica>but not for too much longer
21:36:05  <ArxPoetica>meteor thinks they won the game, but I'm not seeing the stats to prove it
21:36:23  <ArxPoetica>anyway, i'm getting all political-speak, ha ha
21:36:36  <ArxPoetica>more talk than walk blah blah blah
21:36:41  <ArxPoetica>ha ha
21:36:46  <k1i>again, they appeal to the lowest-common denominator
21:36:59  <k1i>spending copious amounts of time writing things like Facebook authentication "smart packages"
21:37:45  <k1i>it's very much a black-box
21:37:47  * dennisma_joined
21:38:21  <k1i>I was curious how that all worked, I opened some of the various smart packages.. they define your schema for you (without 99% of average users knowing what it looks like)
21:39:02  <ArxPoetica>yeah—I think you've (re)convinced me of meteor, ha ha
21:39:17  <ArxPoetica>I let a junior developer talk me into thinking otherwise
21:39:22  <k1i>the fact there is no router or concept of a page is really what does me in
21:39:22  <ArxPoetica>should have known better, lol
21:39:40  <k1i>yes, there are third party packages (Router meteorite package) but the core has absolutely no concept of it
21:40:31  <k1i>my biggest complaint about Derby would be the templating system: but I really love it. It's really well done and angular-like
21:40:54  <k1i>they really force you into using a handlebars-like syntax
21:41:11  <k1i>but it's necessary for mirrored SS/CS rendering, and it's not very obtrusive, and really well-thought-out
21:41:30  * dennismartenssonquit (Ping timeout: 264 seconds)
21:41:36  <ArxPoetica>ah
21:41:43  <k1i>achieving that level of cohesiveness really needs to be done at a core-framework-level
21:41:51  <ArxPoetica>and THAT is where I won't love it at all
21:41:52  <k1i>I doubt we'll ever see Meteor do it without significant refactoring
21:42:08  <ArxPoetica>ANY framework that forces a templating engine on you—that's a problem for me
21:42:10  <k1i>no concept of routes = no way to maintain state between clietn and server
21:42:11  * dennismartenssonjoined
21:42:24  <k1i>well it's HTML with minor markup additions
21:42:26  <ArxPoetica>I use mirrored jade templates
21:42:49  <ArxPoetica>same on front end and back end—I used to be strictly a handlebars
21:42:56  <ArxPoetica>was very snobbish thinking it was the best
21:42:58  <k1i>er
21:43:12  <k1i>you can use Jade with Derby (if you write the markup component for it - it's planned)
21:43:22  <ArxPoetica>on the client?
21:43:23  <k1i>it's just that variables and things are kind of handlebars right now
21:43:30  <ArxPoetica>I see
21:43:33  <ArxPoetica>well that's fine
21:43:35  <k1i>honestly
21:43:45  <k1i>all that happens with the "handlebars" stuff right now
21:43:51  <k1i>is that it gets evaluated into $1, $2, markers
21:44:04  <k1i>the cool place where Derby shines is that the DOM is re-used beyond initial load
21:44:17  <ArxPoetica>Hollow would NEVER have completed in a timely manner if we had used strictly HTML style markup—jade made all the difference in speed of development
21:44:18  <k1i>so it isn't torn down and re-rendered
21:44:28  <k1i>I am a big fan of HAML (ruby guy)
21:44:30  * dennisma_quit (Ping timeout: 264 seconds)
21:44:30  <ArxPoetica>jade === rapid, rapid HTML development
21:44:36  <k1i>its been a very long time since I've written HTML
21:45:11  <ArxPoetica>so anyway
21:45:15  <k1i>so on the initial page load of a derby app
21:45:20  <ArxPoetica>back to the authentication/admin question :P
21:45:30  <k1i>state is captured, checked in the server-side, and then the initial page load contains all of that route's HTML
21:45:48  <ArxPoetica>interesting
21:45:50  <k1i>when a model on the page changes, the DOM isn't completely re-rendered, it's modified in-line (a model gets deleted, that node gets deleted)
21:46:11  <ArxPoetica>and it'll dish up anything remaining via the socket?
21:46:14  <k1i>yes
21:46:17  <ArxPoetica>if so that's pretty cool
21:46:23  <k1i>it's not like Meteor where they just phantomJS the route and hope the state is maintained
21:46:28  <ArxPoetica>so they've solve the exact problem I'm trying to ask you. :P
21:46:56  <k1i>meteor's phantomJS implementation was a stop-gap measure implemented to save face with google and screen-readers
21:47:07  <ArxPoetica>no doubt
21:47:09  <ArxPoetica>btw
21:47:15  <k1i>derby's mirroring does exactly what you'd expect it to - render initial state, and maintain "model -- DOM binding" across the wire
21:47:16  <ArxPoetica>asm.js is going to change everything :P
21:47:38  <ArxPoetica>just throwing out a curve ball
21:48:13  <k1i>heh
21:48:38  <k1i>my issue with ASM.js is that the performance of javascript (specifically V8/node) is only rivaled by really-well-engineered Java
21:49:18  <ArxPoetica>its apples and oranges though
21:49:18  * mdedetrichjoined
21:49:20  <k1i>the fact that everything then gets distilled back to JS really makes everything else moot
21:49:35  <ArxPoetica>what you really should be comparing is the performance of javascript with the new subset of asm.js
21:49:40  <ArxPoetica>because the argument you're making is:
21:50:04  <ArxPoetica>the performance of javascript is rivaled by java
21:50:18  <ArxPoetica>well, yes
21:50:28  <ArxPoetica>but asm.js is much much faster than javascript
21:50:36  <ArxPoetica>apples and oranges :)
21:50:45  <ArxPoetica>(the subset, I mean)
21:50:48  <ArxPoetica>anyway
21:50:49  <ArxPoetica>ha ha
21:50:59  <ArxPoetica>I need to finish up what I'm doing here! :P
21:51:01  <k1i>heh
21:51:04  <k1i>i am keeping my eyes open
21:51:17  <k1i>but, just install the derby package, and create a new app
21:51:24  <k1i>poke through the files - I forget if you like CoffeeScript
21:51:55  <ArxPoetica>haven't experiences enough of it to proclaim it's joys
21:51:56  <k1i>if you can get over the HTML (write your own Jade adapter or wait for an official one) - it's incredible how magical it is
21:52:04  <ArxPoetica>I tend to like original js though I THINK
21:52:13  <k1i>you can generate a derby project in either markup
21:52:44  <ArxPoetica>maybe I'll get a chance to use it during the node knockout competition
21:53:09  <k1i>i have a few very minor (and addressed) complaints about derby
21:53:31  <k1i>1) the OT oplog needs capped and managed (addressed and a fix is in progress)
21:53:55  <k1i>2) model validations don't exist yet (sort of) and ACL patterning is still in the works (both issues addressed)
21:56:21  <ArxPoetica>oh back to that question if you have a sec
21:56:28  <ArxPoetica>(I kept forgetting what it was)
21:56:51  <ArxPoetica>for authentication—does derby store authentication state locally anywhere?
21:56:58  <ArxPoetica>or would that be advised in any scenario?
21:57:17  <ArxPoetica>or should the socket always check with the server if you want to do something that requires an admin role
21:57:24  <ArxPoetica>not sure I'm making sense
21:57:35  <ArxPoetica>and I think you already answered this question—for derby—
21:57:58  <k1i>the planned pattern is
21:58:04  <ArxPoetica>just trying to figure out if it makes sense to set a cookie or sessionStorage variable
21:58:18  <k1i>any operation that gets committed to the database/propagated to other clients gets vetted on the server first
21:58:29  <ArxPoetica>yeah
21:58:35  <k1i>however, since the model is also on the cleint
21:58:46  <k1i>the clientside code can make the assumption that an operation is "ok to do or not"
21:58:50  <ArxPoetica>the model keeps its own client state
21:58:51  <ArxPoetica>right
21:58:57  <ArxPoetica>okay perfect
21:59:03  <ArxPoetica>that answers my question enough
21:59:16  <ArxPoetica>actually, it answers it perfectly
21:59:18  <k1i>with SS since there is no equivalent to racer
21:59:22  <ArxPoetica>right
21:59:24  <ArxPoetica>BUT
21:59:24  <k1i>I'd hit the server for everything
21:59:48  <ArxPoetica>I can still set up my own logical conditions based on different needs, following those guidelines
21:59:50  <k1i>yes
21:59:55  <k1i>if the admin conditions are simple enough
22:00:00  <ArxPoetica>and it also informs how we should work on SS development. :)
22:00:05  <k1i>you can just set a clientside variable for convenience
22:00:10  <k1i>instead of checking each time
22:00:14  <k1i>(set it on login or something)
22:00:36  <k1i>did you see my proof-of-concept rtm-model implementation? with mongoose?
22:01:07  <k1i>https://github.com/korbin/socketstream-0.4/tree/master/mods/rts-model
22:01:30  <ArxPoetica>I think you sent me this a while back
22:01:34  <k1i>havent touched it in a long time, but, this created mirrored model objects across the wire
22:01:35  <ArxPoetica>I need to take a look at it again
22:01:45  <ArxPoetica>this is your own branch then?
22:01:47  <k1i>it was really, really overkill
22:01:49  <k1i>old yes
22:01:51  <ArxPoetica>ok
22:01:55  <ArxPoetica>but it's a good start
22:01:59  <k1i>this mirrored calling conventions
22:02:02  <ArxPoetica>I'm actually going to go open a ticket for this very thing
22:02:11  <k1i>so you could call model instance functions/class functions
22:02:14  <k1i>identically on both the client and server
22:02:29  <k1i>Book.find would do the same thing on both client and server and return the same thing/have the same callbacks
22:02:40  <k1i>clientside methods were magically proxied
22:03:09  * dennisma_joined
22:04:28  <k1i>this was so stupidly overkill now that I am looking at the code haha
22:04:43  <k1i>Derby accomplishes it using a DSL, I wanted native JS calling conventions in SS ;)
22:05:01  <ArxPoetica>this is entirely for models though?
22:05:02  <k1i>yes
22:05:15  <k1i>meteor also accomplishes this kind of code sharing via a DSL
22:05:35  <k1i>and after writing this proof-of-concept for SS, I agree with derby/meteor's method of handling this
22:06:02  <k1i>this was really cool though how it magically re-built methods in the browser and automatically proxied arguments, etc.
22:06:12  <k1i>https://github.com/korbin/socketstream-0.4/blob/master/mods/rtm-mongoose/index.coffee
22:06:40  * dennismartenssonquit (Ping timeout: 268 seconds)
22:07:13  <k1i>it would take that model file and build it into a javascript class
22:07:57  <k1i>er, this model file, and interpolate it with that one
22:07:58  <k1i>https://github.com/korbin/socketstream-0.4/blob/master/example_app/services/model/book.coffee
22:08:08  <ArxPoetica>I just quoted you on github :P
22:08:38  <k1i>i think i just saw
22:10:04  <k1i>reading the thread
22:14:07  <k1i>my solution lacks very important things: any potential for offline support, (therefore) a simple conflict resolution API, and a "general" socketstream-like way of doing things
22:15:04  <k1i>I originally had a much more ambitious goal: you toss a JS class to rts-model and it magically mirrors the class and its instances on both the client and server
22:15:45  <k1i>without having some general "schema" in place (defining server-side functions/client-side-only functions, and defining class methods / instance methods) it got really nasty really fast
22:17:23  * daslichtquit (Remote host closed the connection)
22:17:38  <k1i>heh this recursive function "deflateModel" was really clever
22:31:12  * ArxPoeticaquit (Quit: Leaving.)
22:40:17  * mdedetrichquit (Quit: Computer has gone to sleep.)
22:40:54  * mdedetrichjoined
22:42:00  <paulbjensen>Hi all, I'm looking into a SS app generator for Yeoman at the moment (0.3)
23:02:03  * paulbjensenquit (Quit: paulbjensen)
23:30:28  * colinsullivanjoined
23:32:02  * colinsullivanpart