00:10:54  * k1ijoined
00:11:18  <k1i>owenb: you on?
00:27:56  * cjmjoined
00:58:48  * evangenieurquit (Remote host closed the connection)
00:59:23  * evangenieurjoined
01:03:50  * evangenieurquit (Ping timeout: 256 seconds)
01:04:39  * liorixquit (Remote host closed the connection)
01:05:11  * liorixjoined
01:09:05  * liorixquit (Read error: Connection reset by peer)
01:09:20  * liorixjoined
01:59:39  * colinsullivanquit (Quit: Leaving.)
02:02:56  * lluadquit (Quit: lluad)
02:25:21  * zenoconjoined
02:28:13  * k1iquit (Quit: k1i)
02:31:46  * zenoconquit (Remote host closed the connection)
02:32:59  * k1ijoined
02:34:19  * k1iquit (Client Quit)
03:24:55  * liorixquit (Remote host closed the connection)
03:25:29  * liorixjoined
03:29:57  * liorixquit (Ping timeout: 256 seconds)
03:56:23  * liorixjoined
04:01:53  * colinsullivanjoined
04:04:41  * liorixquit (Ping timeout: 255 seconds)
05:34:51  * k1ijoined
06:15:44  * k1iquit (Quit: k1i)
07:25:37  * liorixjoined
07:30:01  * liorixquit (Ping timeout: 256 seconds)
07:55:41  * liorixjoined
08:15:48  * mtsrjoined
08:57:49  * evangenieurjoined
09:06:41  * liorixquit (Remote host closed the connection)
09:07:16  * liorixjoined
09:11:47  * liorixquit (Ping timeout: 252 seconds)
11:05:05  * vguerrajoined
11:08:07  * evangenieurquit (Remote host closed the connection)
11:08:42  * evangenieurjoined
11:13:17  * evangenieurquit (Ping timeout: 256 seconds)
13:31:35  * liorixjoined
14:04:21  * majekquit (Ping timeout: 248 seconds)
14:04:40  * majekjoined
14:10:02  * zenoconjoined
14:11:36  * liorixquit (Remote host closed the connection)
14:12:12  * liorixjoined
14:12:51  * wafflesaucejoined
14:13:44  <wafflesauce>is there a way to get a list of users currently subscribed to a specific channel?
14:14:54  * zenoconquit (Ping timeout: 256 seconds)
14:16:41  * liorixquit (Ping timeout: 255 seconds)
14:33:10  * liorixjoined
15:17:32  * lluadjoined
15:32:53  * mtsrquit (Ping timeout: 240 seconds)
15:40:21  * zenoconjoined
15:41:00  * vguerraquit (Remote host closed the connection)
15:44:55  * zenoconquit (Ping timeout: 264 seconds)
15:49:15  * cjmquit (Remote host closed the connection)
16:52:27  * liorixquit (Remote host closed the connection)
16:52:59  * liorixjoined
16:57:15  * liorixquit (Ping timeout: 256 seconds)
17:15:22  * liorixjoined
17:30:44  * wafflesauce1joined
17:30:44  * wafflesaucequit (Read error: Connection reset by peer)
18:45:23  * wafflesauce1quit (Quit: Leaving.)
18:52:40  * wafflesaucejoined
19:32:00  * liorixquit (Remote host closed the connection)
19:32:34  * liorixjoined
19:35:57  * liorix_joined
19:36:37  * liorixquit (Read error: Connection reset by peer)
19:40:01  * dennismartenssonjoined
19:58:04  * k1ijoined
20:03:14  * dennismartenssonquit (Remote host closed the connection)
20:28:37  * wafflesaucepart
20:45:25  <owenb>hey k1i
20:46:18  <k1i>owenb: holy shit
20:46:22  <k1i>owenb: been trying to get ahold of yo
20:46:48  <k1i>so, I saw your initial realtime model implementation
20:46:52  <k1i>and I'd like to try and convince you to change it a bit
20:46:52  <owenb>i'm not on here at a lot at the mo. will try to be more when everything is released. focussing on that right now
20:47:09  <owenb>it got committed by mistake. i've pulled it today
20:47:16  <k1i>well
20:47:17  <owenb>it's totally and utterly not ready
20:47:23  <k1i>I'd like to show you my take on it
20:47:27  <owenb>ok sure
20:47:36  <k1i>im reviewing your last commit
20:47:46  <k1i>just to get up to speed
20:48:07  <k1i>however, I saw your initial realtime model implementation, I think it needs to be altered in a few (fairly simple) ways
20:48:14  <k1i>i began writing a proof of concept
20:48:43  <owenb>for sure
20:48:49  <owenb>sounds good :)
20:48:51  <k1i>I believe you should have a service directory /services/models/mymodel.js
20:49:00  <k1i>the model in there would then have 3+ exports
20:49:06  <k1i>exports.config, exports.class, exports.instance
20:49:22  <k1i>exports.config would mainly contain "Driver" - a la, "mongoose," "squel," etc.
20:49:41  <k1i>exports.instance and exports.class would get merged into the prototype/class function respecitvely and proxied over the wire
20:50:11  <k1i>and then, upon the initial load of the app, it would find the model file, create an API tree, and then require() the driver (rtm-mongoose) and merge those proxied methods in
20:51:10  <k1i>to use a model on the clientside, you need to do something like ss.models.load("book", (loaded) ->); - to grab the proxied methods, etc. after runtime
20:51:31  <k1i>and then you could just var myBook = new ss.models["Book"]
20:51:41  <k1i>the trickiest part, which, I found a solution to, would be instance methods
20:51:52  <k1i>if I call an instance function that needs to be handled remotely, you'd need to transfer that individual model's state
20:52:09  <owenb>hmm yes
20:52:16  <k1i>in the individual "driver," you could specify a function (defaulting to object ID)
20:52:27  <k1i>that would be used for state persistence
20:52:31  <k1i>in backbone, ID is used (and is good enough)
20:52:37  <k1i>this would obviously be driver-specific
20:52:52  <k1i>but other than that, it seemed like a pretty elegant and simple way to have real class/instance methods proxied over the wire
20:53:17  <k1i>exports.config, exports.class, exports.instance
20:53:24  <k1i>and potentially an exports.instance.local/remote
20:53:39  <owenb>well it's just a start right now, but i'd love to work with you on this when i get chance to revisit it (likely to be may now as I'm focussing on getting socketstream-server as ready as it can be for Realtime Conf)
20:53:40  <k1i>for functions that can use the model's own (this) attributes on the clientside to do fthings
20:53:59  <owenb>so here are my thoughts
20:54:04  <owenb>in terms of where i want to go next
20:54:46  <owenb>first of all i still would prefer to keep services independent of each other. that said, i think it's reasonable to say if you want to use rts-angular you must install rts-models
20:55:04  <owenb>hence rts-angular are just client-side bindings to the rts-models event emitter
20:55:12  <owenb>that way you can still have /services/models
20:55:16  <owenb>and switch to backbone later on
20:55:19  <owenb>without having to change anything
20:55:50  <owenb>so realtime models should just give the simplest and most lightweight bindings to the client possible
20:56:02  <k1i>yep
20:56:05  <owenb>and then separate wrappers can be made for angular, backbone, ember
20:56:17  <owenb>i'm wanting to take a closer look here: https://www.firebase.com/blog/2013-03-29-firebase-bindings-for-angular.html
20:56:25  <owenb>we could totally use this for SS
20:56:42  <k1i>I really want transparent proxying of instance/class methods
20:56:46  <owenb>in fact if you look at how i attempted to do the live models, the approach happens to be the same
20:56:48  <owenb>yeah
20:56:52  <owenb>this is going to get a lot harder
20:56:55  <k1i>right now I only saw class methods
20:56:56  <owenb>but i know what you're saying
20:56:56  <k1i>proxied
20:57:00  <k1i>in your initial push
20:57:06  <owenb>but it means having to work out where and how to do validatoins
20:57:13  <owenb>can they be done on the client? or do they need the server
20:57:20  <k1i>they need to be doable in both places with the same code
20:57:22  <owenb>anyway - other things to consider:
20:57:26  <k1i>exports.validations - in the model file
20:57:26  <owenb>event streams
20:57:39  <owenb>computed values
20:57:39  <k1i>and in the exports.config in the model, you could override the default validators
20:57:45  <owenb>ok i see
20:58:08  <owenb>so i tried making a realime dashboard using the realtime-models thing i'd done so far
20:58:09  <owenb>it's hard
20:58:12  <k1i>exports.config validatorModule defaults to ss-validators, but, someone could easily just put another validator in there that will require() and follow the same strategy
20:58:14  <owenb>because a lot of values are computed
20:58:44  <k1i>what do you mean
20:58:55  <owenb>so i had a model called totalHits
20:59:01  <owenb>and i find a record on that
20:59:08  <owenb>called something like 'widget1'
20:59:16  <owenb>so give me the total hits for widget 1
20:59:29  <owenb>but to caculate that i need to do a sum of all keys in redis
20:59:36  <owenb>so the data is not real, it's calculated
20:59:58  <owenb>so either we say realtime models is not for that, or we find a way to do this
21:00:03  <k1i>uh
21:00:08  <k1i>why not just have a server-proxied class method
21:00:11  <k1i>err
21:00:16  <k1i>this is a server-proxied instance method
21:00:17  <k1i>so in the clientside
21:00:32  <k1i>you have var widget1 = new ss.models["widget1"];
21:00:44  <k1i>err
21:00:45  <k1i>sorry
21:01:17  <k1i>var widget1 = new ss.models["totalHits"].find("widget1");
21:01:26  <k1i>widget1.totalHits();
21:01:55  <k1i>the ID of the model gets proxied over the wire and the model gets re-instantiated on the server-side, and the function gets called
21:02:05  <k1i>but the calling convention is the same on both the client and the server
21:02:22  <owenb>sure that's ok, but what happens when the data changes
21:02:27  <owenb>and there is a new key created
21:02:28  <k1i>it gets recalculatd
21:02:42  <k1i>describe to me what totalHits looks like
21:02:57  <owenb>it's a redis list. so i rpush() another key onto the list
21:03:14  <k1i>can you describe it in an SQL fashion
21:03:16  <owenb>but i also want to get several metrics from this
21:03:20  <owenb>which change in realtime
21:03:22  <owenb>sure
21:03:29  <owenb>so i INSERT a row
21:03:33  <k1i>into a table with what schema
21:04:00  <owenb>INSERT useragent, widgetVersion, VALUES 'MSIE", 'widget1'
21:04:02  <owenb>something like that
21:04:14  <owenb>now i want my dashboard to display the total number of hits for widget 1 and widget 2
21:04:26  <owenb>in realtime, everytime there is a change to the data
21:04:32  <owenb>but i also want a realtime conversion rate
21:04:43  <owenb>which uses the CLICKS table ;)
21:05:08  <owenb>so when either the HITS or the CLICKS table changes, my conversion rate needs to change too
21:05:12  <k1i>the issue here
21:05:13  <k1i>ah
21:05:14  <k1i>okay
21:05:14  <k1i>so
21:05:15  <k1i>rails solved this already
21:05:17  <k1i>you need to do this
21:05:46  <k1i>TABLE "widgets" id:integer, name:string, created_at:datetime, updated_at:datetime
21:06:03  <k1i>TABLE "hits" id:integer, widget_id:integer, agent:string
21:06:12  <k1i>TABLE "clicks" id:integer, widget_id:integer
21:06:34  <k1i>part of the driver that handles the relationship between hits/widgets (in this case, a MySQL driver)
21:06:56  <k1i>will "touch" (update updated_at) whenever hits/clicks have a record created with the widget_id of the widget you are watching
21:07:09  <k1i>so the individual record in widgets will get updated whenever a related record is created
21:07:20  <k1i>this is how cache breaking is handled in rails, and this is essentially cache breaking
21:07:27  <owenb>yup
21:07:37  <owenb>many of the time it's just simple counters
21:07:41  <k1i>so as soon as that main widget is changed
21:07:45  <owenb>and we may well decide all this is too complicated for realtime models
21:07:47  <k1i>you redraw all of the dependent data
21:07:52  <k1i>I don't think so at all
21:07:56  <owenb>and that realtime models should just deal with real tangible data
21:08:03  <k1i>no
21:08:07  <k1i>this is a widget
21:08:08  <k1i>errr
21:08:17  <k1i>this is an instance method on the model "widget"
21:08:39  <k1i>so whenever you call the instance method, it will re-count everything, etc.
21:08:52  <k1i>but the "order to recall" is based on observing the "updated_at" in this case
21:08:58  <k1i>this is totally a datastore-driver related thing
21:09:08  <k1i>realtime-model isn't supposed to be an ORM
21:09:23  <k1i>it is supposed to be a proxy (at least my take on it) between clientside model methods and serverside model methods/definition
21:09:35  <owenb>yes
21:09:39  <owenb>i really don't want to get into orm
21:09:43  <owenb>someone else can do that if they want
21:09:47  <k1i>the mongoose driver would handle that kind of a scenario entirely different than the activerecord-like functionality I just described
21:09:55  <owenb>it's an observable proxy i guess
21:10:00  <owenb>yes
21:10:06  <k1i>as would the redis one
21:10:17  <k1i>but, the main thing would stay the same
21:10:21  <k1i>instance method to calculate those values
21:10:25  <k1i>an observe on the model itself
21:10:39  <k1i>and whenever the model updates, the observe fires and the function is recalled
21:10:47  <k1i>now, one cool thing that can be done at this point, though, is cacheable functions
21:11:03  <k1i>the datastore driver would internally cache the output of those queries
21:11:10  <k1i>(not related to realtime-model)
21:12:03  <k1i>there are some assumptions that will need to be made, though, to make things like instance methods work over the wire
21:13:40  <owenb>yes indeed
21:14:05  <k1i>the biggest problem I had when doing this
21:14:11  <owenb>well i'm unlikely to get chance to do any more work in this area for a while. if you fancy giving it a go, i'd love to see what you come up with
21:14:11  <k1i>was transmitting the dynamically generated model definitions to the client
21:14:25  <k1i>since, system.js is generated as soon as the server starts
21:14:29  <owenb>i really don't think you should
21:14:34  <owenb>just send the instructions to reproduce that
21:14:42  <k1i>what I am saying is
21:14:50  <owenb>system js will one day be inside a pre-build minified file on a CDN
21:14:52  <k1i>right now, without a way to send models on the initial pageload since system.js is static
21:14:54  <k1i>ok
21:15:02  <k1i>I have to run an ss.model.get("modelname")
21:15:09  <k1i>to download a copy of the model function prototype
21:15:10  <owenb>yes
21:15:16  <owenb>indeed
21:15:21  <owenb>but only for the ones you need
21:15:22  <k1i>and this is intended functionality?
21:15:23  <k1i>yea
21:15:46  <owenb>well it works. but i'm not yet convinced we need this at all
21:15:50  <owenb>but i'm happy to see it in action
21:15:51  <k1i>what do you mean?
21:15:52  <owenb>and decide
21:15:54  <k1i>proxying?
21:16:09  <owenb>to be able to define models and methods on the server and get them sent to the client
21:16:25  <k1i>i want to be able to call functions the exact same way on the server as the client
21:16:38  <k1i>var myWidget = ss.models.widget.find(1);
21:16:48  <k1i>myWidget.changeColor("blue");
21:16:54  <k1i>or ss.models.widget.deleteAll
21:16:55  <owenb>but if your function needs data from the server it's hard. a lot of magic needs to happen to make this a reality.
21:17:03  <owenb>then you have to think about security
21:17:10  <owenb>there's a lot to conisder
21:17:14  <k1i>no, because any function that needs data form the server just gets executed there anyway
21:17:17  <k1i>that isnt a local function
21:17:22  <k1i>it's a remotely proxied functio
21:17:25  <k1i>a la rts-rpc
21:17:26  <owenb>i see
21:17:41  <owenb>then why not use rpc-style? just execute an action?
21:17:47  <owenb>it's more explicit
21:17:55  <owenb>so you would still have delete all
21:17:56  <owenb>etc
21:18:00  <owenb>but you pass it as a string
21:18:03  <owenb>and hence no overhead
21:18:10  <owenb>(do discover what methods i can call)
21:18:17  <owenb>*to
21:19:38  <k1i>because
21:19:42  <k1i>of the serverside eventuality
21:19:53  <k1i>also, because you are persisting properties within the model itself
21:19:55  <k1i>like backbone
21:20:02  <k1i>and not every function is going to be remote
21:20:12  <k1i>there will be local ones that do simple reformatting, etc. that can easily be executed without a round-trip across the wire
21:20:18  <k1i>I hate that model.execute() shit that meteor uses
21:20:43  <k1i>if the model is the exact same on the client as the server, you can re-use code that does cool stuff
21:20:54  <k1i>myModel.find is the same on the server as the client
21:21:22  <k1i>and mainly because instance methods require this
21:21:58  <k1i>that model.execute() shit works for class methods, but if you are going to emulate activerecord (like I hope to do), the model has to exist in memory in the client with instance methods attached
21:22:07  <k1i>honestly it's just a loop that modifies the function.object.prototype
21:22:19  <owenb>i see
21:22:27  <k1i>this is something I wrote for proof of concept
21:22:35  <k1i>right now, with realtime-model and rts-angular
21:22:43  <k1i>the clientside has no idea of the "possible functions" that can be executed
21:22:54  <owenb>no. but i would argue, nor should it
21:22:55  <k1i>or default values, or IDs, or anything
21:23:10  <owenb>the only time it's useful really is if you want to autocomplete on the Chrome console
21:23:13  <k1i>I believe function myModel() should essentially have the same members/methods on the client as the server
21:23:23  <k1i>but on the clientside, some of these are proxied to RPC
21:23:32  <k1i>and then any code you write can be used either place seamlessly
21:23:42  <k1i>but yeah, the autocomplete would be sweet, too.
21:23:43  <owenb>i just worry about the 'discovery lag'
21:23:54  <owenb>but it only benefits the developer debugging
21:23:59  <owenb>it hurts things in productoin
21:24:03  <k1i>well
21:24:07  <owenb>where you can't do anything with a model before you first download it's prototype
21:24:13  <k1i>the only reason that is the case is because you cant send the prototype over the wire with the client load
21:24:18  <k1i>backbone has been doing this forever
21:24:22  <owenb>sure
21:24:24  <k1i>you send every model prototype on initial pageload
21:24:27  <owenb>i think we must think about that too
21:24:28  <owenb>backbone
21:24:38  <owenb>a lot of people put their model logic in there
21:24:39  <k1i>the problem is, SS doesn't allow me to send model prototypes because of how system.js is generated
21:24:40  <k1i>shit
21:24:58  <k1i>I don't mind putting the model prototypes into the client section of system.js
21:24:59  <k1i>but
21:25:06  * evangenieurjoined
21:25:08  <k1i>there is no way to send them at the moment
21:25:37  <owenb>if you do it means you expose all methods to every hacker. i'm not advocating security through obscurity here, but it something to think about
21:25:38  <k1i>I can't access /services/models/mymodel.js when system.js is generated
21:25:46  <owenb>no
21:26:06  <k1i>yes, it does expose every method, but, yeah, security through obscurity isn't a good idea
21:26:18  <k1i>it doesn't expose any remote function prototypes
21:26:20  <k1i>only their names.
21:26:37  <owenb>i think you should write a solution like this. one that downloads the prototypes
21:26:41  <owenb>over the ws
21:26:41  <k1i>also, theoretically, you should be able to have private functions as well - this is just an effect of rails being shitty
21:26:42  <k1i>err
21:26:44  <k1i>JS being shitty
21:26:47  <owenb>yeah
21:27:10  <k1i>shit, maybe we assume some sane defaults
21:27:13  <k1i>and do like
21:27:35  <k1i>exports.methods.private.class = { findAllBlueWidgets: -> };
21:27:43  <owenb>personally, unless it works like a dream, i'd rather stick with a rpc-esque solution which just monitors which client sees what records and notifies them of updates. but then again i may be wrong and find what you're advocating is just what i want
21:27:47  <k1i>exports.methods.public.instance = { deleteMe: -> };
21:28:16  <k1i>I believe the notification of update thing is 100% the job of realtime model
21:28:23  <owenb>for sure
21:28:25  <k1i>also
21:28:28  <k1i>just some food for thought
21:28:32  <k1i>everyone hates the meteor.call bullshit.
21:28:33  <k1i>everyone.
21:28:51  <k1i>they advertise "models" in both places (client/server), but everyone ends up using meteor.call because of the limitations of functions you can send to the client
21:29:07  <k1i>a la, meteor wants what I am describing, but can't do it do to architectural concerns
21:29:29  <k1i>the Meteor.call way of doing things is totally unnecessary and makes it so your clientside code has to look different than your serverside code
21:31:21  <k1i>also, some more food for thought
21:31:53  <k1i>if I want to make "Mongoose in the client" a la minimongo, I'd have to rewrite everything in mongoose to make use of the model.rpc("func") notation rather than just copy/paste and roll
21:32:14  <k1i>it's like browserify - I should be able to use node modules in the client, rather than adding abstraction that makes that impossible
21:32:19  <owenb>i think you have the huge advantage here of spending a lot of time with Meteor. something I haven't really done. i just keep abreast of the changes and am very friendly with the devs. i like what they have done, but I'm sure there are ways to improve the model system
21:32:33  <k1i>I never thought about this before
21:32:44  <k1i>but, this is the biggest reason for the "proxied prototypes" method
21:33:03  <k1i>if I want to make Mongoose work in the client, mongoose assumes all models are javascript functions in their own "way", and you can call functions on them just as i've described
21:33:21  <k1i>some of the functions that mongoose has are combinations of other class/instance methods in mongoose
21:33:34  <k1i>if you change the calling convention, that entire driver becomes unusable
21:34:12  <k1i>I havent spent too much time with meteor, but I've dug heavily into the source of both meteor and derby
21:34:47  <k1i>I know that the model.rpc() method thing is hated over there, and makes more sense, quite honestly, for them, because they use fibers
21:34:52  <k1i>SS is asynchronous, as are any node libraries SS is using
21:36:46  <k1i>again, the trickiest thing, IMO about doing this, is how to replicate model state in the serverside
21:37:21  <k1i>so when I call an instance method, the real (non-proxied) version of the instance method on the serverside can do what it needs to
21:37:52  <k1i>backbone handles this with just a simple assumption of a model having an "ID" property, we could/should assume the same (and allow overriding if need be)
21:38:05  <owenb>yes
21:38:11  <k1i>https://github.com/ianserlin/now-mongoose is a cute exmaple
21:38:18  <owenb>i see true models as having an 'id' of some sort
21:38:25  <k1i>he puts this in a comment
21:38:27  <k1i>at the bottom of the rEADME
21:38:28  <k1i>NOTE: Model instance level methods are more tricky and I haven't figured out how to proxy those yet, any suggestions welcome!
21:38:34  <k1i>I believe firmly, that, I have that solution
21:38:37  <owenb>things like the 'tell me how many hits widget a got' may not have an ID at all
21:38:46  <k1i>those arent models
21:38:49  <k1i>I believe in that case
21:38:52  <k1i>the model would be "widget"
21:38:55  <owenb>which is why I'm doubtful it should be handled the same way
21:38:57  <k1i>and the "Tell me how many hits" is an instance method
21:39:01  <k1i>on said widget
21:39:01  <owenb>yes
21:39:07  <k1i>that does the actual calculation
21:39:07  <owenb>but the key is getting realtime updates
21:39:10  <owenb>to that value
21:39:13  <owenb>the calculating
21:39:16  <k1i>whenever the "widget" issues a "change" event
21:39:19  <owenb>it may have to be polled on the server
21:39:20  <k1i>the clients recall
21:39:24  <k1i>"getTotalHits"
21:39:26  <owenb>yeah
21:39:26  <k1i>on that instance of the widget
21:39:36  <k1i>but the model itself isn't a collection of data
21:39:38  <k1i>the model itself is the widget
21:39:42  <k1i>Hit is another model
21:39:45  <k1i>Click is another model
21:39:45  <owenb>yes
21:39:52  <k1i>both of those models have routines in their "Save" functions that update their parent model
21:40:05  <k1i>which in turn handles the "observer" update event
21:40:22  <k1i>pretty simple if you think of it in terms of ths
21:40:34  <k1i>and that actual relationship structure isn't something realtime-model should handle, IMO
21:40:49  <k1i>there are other ORMS/activerecord clones that pull off this exact relationship system (touching, etc.) that exist today
21:41:08  <k1i>a realtime-model "driver" that links whatever ORM that may be with realtime-model, is in charge of handling that kind of functionality
21:41:41  <k1i>also, something more cool I was working on with my implementation (initially)
21:41:50  <k1i>the entire api buildout of the model gets sent to the driver
21:41:58  <k1i>model.js's "createApiTree"
21:42:06  <k1i>so, you can add other, driver-specific exports
21:42:18  <k1i>for instance, if my exports.config.driver == "Mongoose", mongoose then expects an exports.schema as well
21:45:00  <owenb>i think as soon as we talk about drivers and save methods automatically updating other relationships it starts becoming an ORM, or at least a wrapper around one. That's not a bad thing per-se, and there is a huge demand for something like this - but we just need to be clear about what we are building and what it is. I have a feeling what you are wanting is a
21:45:00  <owenb>layer above the core 'observing' stuff I was thinking of - but that's fine, they could easily work well together. brb food
21:45:10  <k1i>well
21:45:17  <k1i>I want things to be low level
21:45:26  <k1i>which is why the "driver" implementation is where the ORM-functionality gets implemented
21:45:42  <k1i>"driver" is simply a way to "require" other code that people can write to interact with models
21:45:46  <k1i>and proxy it out
21:46:22  <k1i>technically, all it really is, is a JS object that gets merged into the api tree generated out of model.js, exposing functions etc, and then the realtime-model does its job of proxying
21:46:51  <k1i>it's just a way to send model.js to mongoose and get a tailored response that is proxyable in this kind of an environment
21:47:17  <k1i>the save methods updating other relationships is a very driver-specific thing
21:48:21  <k1i>in a model file (for a hit), this would be like this: exports.methods.instance.save: -> var myParentWidget = ss.models["widget"].find(self.widget_id); myParentWidget.touch();
21:48:23  <k1i>pretty elegant ,IMO
21:48:42  <k1i>obviously add a super() up there, but you get the idea
21:52:24  <k1i>this actually sounds cooler and cooler as I talk about it
21:53:08  <k1i>exports.methods.private.instance.beforeSave could be implemented in the individual drivers to be called in .save if it exists (totally SS-independent and irrelevant)
21:54:29  <k1i>at the end of the day, though, the outline of what we are building is just a system to proxy whole javascript objects (with a somewhat-defined structure) on both a client and server, and allow the intermingling of methods in between them with the same calling convention
21:55:14  <k1i>validators, ORMs, schemas, all that extra bullshit is exposed (and just proxied) in the "driver"
21:55:45  <k1i>we obviously release it with a base driver implementation (I will write mongoose) that will get expanded upon, etc, but isn't totally necessary
22:19:44  * liorix_quit (Remote host closed the connection)
22:24:58  * zenoconjoined
22:27:40  * zenoconquit (Remote host closed the connection)
22:44:50  <owenb>hey
22:45:07  <owenb>k1i : I think you should build this
22:45:35  <owenb>the realtime service api may still change a little, but I'm happy with the overal design and don't expect to make too many changes to the realtime server bit from now on
22:45:51  <k1i>I will build this
22:45:56  <owenb>great
22:45:59  <k1i>I was just worried about skew
22:46:06  <owenb>how so?
22:46:39  <k1i>well, if there are a bunch of model implementations on top of realtime-service, I dont know that we will get the activerecord-like community that exists with rails
22:46:50  <k1i>i believe, honestly and firmly, after spending a ton of time looking into frameworks etc.
22:46:55  <k1i>that this is the biggest sticking point for SS/other frameworks (model implementation)
22:47:04  <k1i>that and scaling
22:47:07  <owenb>iyes
22:47:08  <owenb>yes
22:47:15  <owenb>scaling is really hard
22:47:18  <owenb>but doable
22:47:21  <k1i>did you see connect-redis-realtime?
22:47:21  * liorixjoined
22:47:26  <owenb>no?
22:47:33  <k1i>https://github.com/korbin/connect-redis-realtime I wrote this.
22:47:43  <k1i>it is in npm
22:47:59  <k1i>it's an LRU-cached version of connect-redis that utilizes pubsub for updates
22:48:07  <k1i>like we talked about
22:48:43  <owenb>this is great :)
22:48:49  <k1i>so you shut off caching in SS, use this session-store, and it keeps sessions in memory while persisting them to redis, communicating updates over the redis built-in pubsub
22:48:59  <owenb>hopefully you spotted the caching stuff i put in for sessions
22:49:02  <k1i>yep
22:49:04  <owenb>great
22:49:07  <k1i>works really well
22:49:08  <k1i>with SS .3
22:49:15  <owenb>i'll give it a go with 0.4 when i get a moment
22:49:18  <k1i>I did
22:49:20  <k1i>worked just fine
22:49:22  <owenb>as for skew
22:49:26  <owenb>they key is layers
22:49:37  <owenb>each as separate testable libraries that do one thing
22:49:39  <k1i>I believe realtime-model should just be a proxy layer
22:49:51  <k1i>i wish I could leverage rts-pubsub within realtime model
22:50:59  <owenb>what i mean is, people should be able to select as much realtime model functionality as they need. i would probably go for a really lightweight thing, some want a full meteor-like ORM. but each layer should build on each other
22:51:12  <owenb>i think and hope it's possible to do it like that
22:51:35  <k1i>yeah
22:51:44  <k1i>I feel like you should (technically) be able to use realtime-model without a "driver" specified at all
22:51:53  <k1i>technically it could just be used to contain methods and do clientside model manipulation
22:51:57  <k1i>for very basic stuff
22:52:02  <k1i>or an in-memory driver could exist
22:52:18  <owenb>i'm just not sure yet
22:52:29  <k1i>I believe the over-the-socket proxying should be very clever (I have this in mind), and the leave the drivers free for people to add cool functionality
22:52:31  <owenb>but i know that whatever observes the data that's going in and out of the client needs to be one thing
22:52:43  <owenb>and whatever lets you define a schema and handle validations needs to be another
22:52:46  <owenb>but they can use each other
22:52:57  <k1i>yeah, that's pretty much what I am talking about with "drivers"
22:52:58  <owenb>right i must go.
22:53:01  <k1i>all "driver" really is a "require"
22:53:02  <owenb>cool ok :)
22:53:06  <k1i>gotcha
22:53:22  <k1i>again
22:53:41  <k1i>the biggest complication I am running into right now, I think ,is the ability to send model prototypes in system.js
22:54:03  <k1i>I wish I could access services/model/model.js pre-system.js build
22:54:21  <owenb>don't do it lol. think cdns and varnish cache
22:54:27  <owenb>not everyone will want the same models
22:54:35  <owenb>you should only get what you need
22:54:37  <k1i>I guess
22:54:42  <k1i>I don't mind initializing a meteor app
22:54:54  <k1i>and calling ss.models.get("modelname") to load the prototype
22:54:57  <k1i>err
22:54:58  <k1i>angular app
22:55:00  <k1i>controller
22:55:30  <k1i>it would be really cool if you could do a browserify require()
22:55:31  <owenb>if you really want protoypes in the client, do something like rtsModel('products, function(err, model))
22:55:36  <owenb>then you can call model.find()
22:55:43  <owenb>model.checkout()
22:55:45  <owenb>whatever
22:55:46  <k1i>ye[
22:55:47  <k1i>yep
22:55:54  <k1i>I want to be able to do instances of models though as well
22:55:59  <owenb>yeah
22:55:59  <k1i>.find returns a new model instance, etc.
22:56:04  <owenb>i get it
22:56:14  <owenb>but think how it plays with angular and backbone/ember models
22:56:16  <owenb>anyway
22:56:17  <owenb>must go
22:56:19  <k1i>gotcha
22:56:22  <k1i>later
22:56:22  <owenb>i'll leave you to it
22:56:24  <owenb>indeed
22:56:28  <owenb>and thanks :)
22:56:31  <owenb>chat soon
23:24:13  * sveisveiquit (Ping timeout: 246 seconds)