Zotonic
Zotonic
zotonic@conference.zotonic.com
Wednesday, 9 January 2013< ^ >
arjan has set the subject to: Zotonic - the Erlang Content Management Framework
Room Configuration

GMT+1
[00:19:24] Maas leaves the room
[02:10:21] Andreas Stenius leaves the room
[02:10:48] Andreas Stenius joins the room
[05:22:46] Andreas Stenius leaves the room
[05:22:46] Andreas Stenius joins the room
[07:13:00] Arjan joins the room
[07:36:11] Arjan leaves the room
[08:37:17] Arjan joins the room
[09:11:42] <Andreas Stenius> Interesting...
[09:11:42] <Andreas Stenius> but why do they mix in swedish in the otherwise english looking paper.. ?
[09:11:42] Andreas Stenius reading... :)
[09:26:35] <Andreas Stenius> wow, I've never heard of PURE before: http://beebole.com/pure looks cool! :)
[09:29:15] maas.maarten.zeeman joins the room
[09:29:52] <maas.maarten.zeeman> It is nice to read how people think about zotonic.
[09:32:01] <Andreas Stenius> yeah, and we had come "the furthest" feature wise already early in 2010. I guess only some low level documentation were missing since they preferred to see it as a publishing tool rather than a web framework.. :p
[09:32:46] <maas.maarten.zeeman> Also found another paper by some students. They dissed it because they couldn't implement websocket stuff easily. That is also fixed now.
[09:35:24] <maas.maarten.zeeman> I searched google with zotonic filetype:pdf
[09:37:40] <Andreas Stenius> ok, so we're probably going to see more papers over the years.. so, we can grab the feedback from current papers and watch the progress and see how it is being received :)
[09:38:40] <maas.maarten.zeeman> We have to do more marketing.
[09:38:56] <maas.maarten.zeeman> Dissing it because we use postgres is stupid.
[09:39:25] <maas.maarten.zeeman> For the tech people we need to communicate our vision.
[09:39:38] <Andreas Stenius> yeah, I found that argument quite uneducated too..
[09:39:48] <maas.maarten.zeeman> Proven technology
[09:40:06] <maas.maarten.zeeman> But we have to communicate how much clients we can handle with standard hardware.
[09:40:15] <maas.maarten.zeeman> That is already huge.
[09:40:45] <maas.maarten.zeeman> And with the future elastic plans.
[09:40:57] <maas.maarten.zeeman> That probably calls for a roadmap of some sorts.
[09:41:26] <maas.maarten.zeeman> It is all about perception in these situations.
[09:52:06] <maas.maarten.zeeman> http://www.it.uu.se/edu/course/homepage/projektDV/ht10/TrapExit.productreport.pdf
[09:52:10] <maas.maarten.zeeman> This is the other one.
[09:53:06] <maas.maarten.zeeman> We also have to communicate why a cmf has special needs regarding the db layer.
[09:53:26] <maas.maarten.zeeman> Especially the elastic version.
[09:53:47] <maas.maarten.zeeman> Didn't think it was this important.
[09:54:25] Protagores joins the room
[09:55:29] <Arjan> well at least in the last paper we do a lot better than Chicago Boss :p
[09:55:38] <maas.maarten.zeeman> haha
[09:58:07] <maas.maarten.zeeman> Why do all these people make it complex first and then try to make it scalable?
[10:02:27] <maas.maarten.zeeman> Damn, even making something like mod_couch is really easy.
[10:06:51] <maas.maarten.zeeman> Seriously, we have to communicate our "vision".` more.
[12:44:07] Marc Worrell joins the room
[12:45:28] <Marc Worrell> @maas - you found some report dissing Zotonic because of using pgsql?
[12:47:02] <maas.maarten.zeeman> Dissing is a great word but, yes.
[12:47:27] <maas.maarten.zeeman> Wait here: http://uu.diva-portal.org/smash/get/diva2:428012/FULLTEXT01
[12:48:01] <maas.maarten.zeeman> It is not scalable because it uses postgres.
[12:50:27] <maas.maarten.zeeman> My conclusion, we should definitely do more about our marketing.
[12:52:31] <Marc Worrell> That TrapExit report is clearly written by people inexperienced in building web systems.
[12:52:55] <Marc Worrell> What a nonsense "It is not scalable because it uses postgres."
[13:06:25] <Marc Worrell> But they are all students. And indeed, we need more white papers :)
[13:06:40] <Marc Worrell> (continuing with the zotonic performance article….)
[13:29:33] Andreas Stenius leaves the room
[13:30:03] Andreas Stenius joins the room
[13:50:41] <maas.maarten.zeeman> Interesting to read how people look at it. Very different from what I thought.
[13:52:20] <Marc Worrell> It is the perspective of people coming from university and wanting to build a web application.
[13:52:40] <Marc Worrell> It is different when you have been there, done that, go the t-shirt.
[13:53:25] <Marc Worrell> Then you just want to get things done…. and you know that doing much heavy Javascript lifting in the user-agent is a separate class of pain… as they also admit (indirectly) in their conclusions.
[13:56:25] <maas.maarten.zeeman> What I don't understand is that they immediately start with separating stuff in layers. They go: we need to store stuff, lets select a db Without first looking at situation as a whole.
[13:58:06] <Marc Worrell> yeah, that shows how inexperienced they are.
[13:59:12] <Marc Worrell> Is interesting that interns make this kind of documents for companies. Maybe we should make ourselves very attractive for interns, possibly by providing partial studies they can easily reproduce :p
[13:59:49] <maas.maarten.zeeman> Yeah, right, these are comp-sci students eager to learn stuff.
[14:03:07] <Andreas Stenius> that's actually a pretty clever idea. I guess the companies are more willing to go on using the tools used in the prototype resulting from the thesis..
[14:03:07] <Andreas Stenius> darn jabber.org is sloooww... :/
[14:06:33] <maas.maarten.zeeman> How should we do that? Write a blog post on the requirements of the storage layer of a web application?
[14:08:27] <maas.maarten.zeeman> And for future stuff in the pipeline? A roadmap maybe with some rough explanation on elastic? That might reduce some postgres is not scalable worries.
[14:16:01] <Arjan> maas.maarten.zeeman: are you aware of this? https://docs.google.com/a/miraclethings.nl/document/d/1geegFN7sIDWSJCn8bAolN4iEZnpV-VdUC92QahDn4D4/edit#heading=h.tegj505793od
[14:16:41] <maas.maarten.zeeman> That is a pretty nice strategy I think. There are others writing these kind reports too. These people do not have time to look into things in much detail.
[14:17:30] <Arjan> yep
[14:17:37] <Arjan> well this thing will become part of a book ;)
[14:31:04] <maas.maarten.zeeman> Nice
[14:40:42] <Arjan> finally! http://zotonic.com/themovie
[14:46:13] protagores joins the room
[14:46:13] Protagores leaves the room
[15:29:20] <Marc Worrell> Core team: please check https://docs.google.com/a/maximonster.nl/document/d/1geegFN7sIDWSJCn8bAolN4iEZnpV-VdUC92QahDn4D4/edit#
[15:29:50] <Marc Worrell> Just added the "Erlang VM considerations" chapter
[15:29:56] <Arjan> nice!
[15:30:09] <Marc Worrell> Also changes to webmachine part
[15:30:23] <Marc Worrell> Now on to the SQL/NoSQL/whateverSQL
[15:32:07] <Arjan> goed bezig!!!
[15:33:05] <Marc Worrell> It is shaping up nicely :)
[15:33:32] <Arjan> absolutely
[15:33:35] <maas.maarten.zeeman> Great stuff
[15:36:32] <maas.maarten.zeeman> Btw, reading this. What we recently found out is that on long lasting connections packet loss somewhere can become problematic. Not good for real time things.
[15:37:33] <Marc Worrell> Then we have to solve that… or is the TCP/IP protocol blocking good solutions?
[15:38:50] <maas.maarten.zeeman> It causes retransmissions in tcp layer.
[15:39:13] <Marc Worrell> and what is the result of that? timeouts?
[15:39:27] <maas.maarten.zeeman> not timeouts, but messages coming in with a big delayu
[15:39:47] <maas.maarten.zeeman> and things feeling sluggish
[15:41:29] <maas.maarten.zeeman> was investigating what we can do about it. have build a client side ping thingy to measure the delay
[15:41:35] <Marc Worrell> when you can do things out of sequence then you might want to consider opening multiple channels
[15:42:14] <maas.maarten.zeeman> or do that when the timeouts buildup
[15:42:24] protagores is now known as Protagores
[15:43:36] <maas.maarten.zeeman> skipping stuff is ok, out of sequence not.
[15:44:03] <maas.maarten.zeeman> i think i have to wait until webrtc is ready :-p
[15:45:59] <maas.maarten.zeeman> For now I just want the end user to be aware of it.
[16:10:16] <maas.maarten.zeeman> Also cool... paper from 2010. Speeding up sqlite with cuda. http://pbbakkum.com/db/bakkum.sql.db.gpu.pdf
[16:47:09] Andreas Stenius leaves the room
[16:47:56] <Marc Worrell> hei maas, how did you call the "watchdog" processes you want to use for restarting failed processes?
[16:48:33] <maas.maarten.zeeman> haha. I have from the book release it.
[16:48:38] Andreas Stenius joins the room
[16:48:45] <Marc Worrell> are they called "watchdog"?
[16:49:22] <maas.maarten.zeeman> no they call it circuit breaker
[16:49:45] <maas.maarten.zeeman> but for erlang the situation is different :-)
[16:50:19] <Marc Worrell> yep - but good for replacing the z_supervisor thingy
[16:50:23] <maas.maarten.zeeman> https://github.com/mmzeeman/breaky
[16:50:38] <Marc Worrell> "Restructuring the supervisor structure using circuit breaker processes instead of the custom z_supervisor. This should make the structure more flexible, enables better code upgrade of modules and make the system more robust."
[16:51:22] <maas.maarten.zeeman> shutdowns are sometimes problematic. There is an ordering issue somewhere
[16:51:47] <Marc Worrell> as always, startup and shutdown are the hard parts
[16:52:48] <Andreas Stenius> with a well defined startup order, shutdown ought to be done in reverse order of that of the startup
[16:53:22] <Marc Worrell> how does the OTP supervisor do it?
[16:53:25] <maas.maarten.zeeman> if you follow the otp guidelines, yes :-)
[16:53:31] <Marc Worrell> :p
[16:54:42] <maas.maarten.zeeman> I think they follow the spec. dunno for dynamically started childs
[16:55:21] <Arjan> dynamically started children should not depend on each other?
[16:55:42] <maas.maarten.zeeman> well for the shut down order.
[16:56:17] <maas.maarten.zeeman> if a proc crashes and is restarted when is it shutdown when the supervisor stops?
[16:56:44] <Andreas Stenius> I don't think that shutdown order is considered by the otp supervisor...
[16:56:55] <maas.maarten.zeeman> hmm.
[16:57:03] <Andreas Stenius> there's at least no mention of shutdown (or startup) order in the docs that I could find...
[16:57:42] <Andreas Stenius> the closes I found was: rest_for_one - if one child process terminates and should be restarted, the 'rest' of the child processes -- i.e. the child processes after the terminated child process in the start order -- are terminated. Then the terminated child process and all child processes after it are restarted.
[16:57:59] <Andreas Stenius> and still, they don't talk about the order of the affected specs...
[17:01:23] <maas.maarten.zeeman> 5.10  StoppingSince the supervisor is part of a supervision tree, it will automatically be terminated by its supervisor. When asked to shutdown, it will terminate all child processes in reversed start order according to the respective shutdown specifications, and then terminate itself.
[17:01:38] <Marc Worrell> :)
[17:02:05] <maas.maarten.zeeman> Hmm, no mention of dynamic children.
[17:03:22] <maas.maarten.zeeman> with a timeouts of course, after that it just brutally kills it children.
[17:05:36] <Andreas Stenius> the missing link: http://erlang.org/doc/design_principles/sup_princ.html
[17:05:54] <maas.maarten.zeeman> Sorry.
[17:06:24] <Andreas Stenius> np. I found it :p
[17:06:50] <Andreas Stenius> (and I didn't provide link for my quote either...)
[17:12:06] <maas.maarten.zeeman> They shutdown dynamic children in the reverse order which they have been started. Logical.
[17:12:32] <maas.maarten.zeeman> (from supervisor.erl)
[17:24:34] Arjan leaves the room
[17:27:43] <Marc Worrell> Ok, core team, read and shoot holes in the performance article!
[17:44:37] maas.maarten.zeeman leaves the room
[19:06:51] Arjan joins the room
[19:13:30] <Arjan> reading the article top down
[19:21:09] Andreas Stenius leaves the room
[19:21:09] Protagores leaves the room
[19:22:43] Arjan leaves the room
[19:24:44] protagores joins the room
[19:27:28] Andreas Stenius joins the room
[19:31:39] <Marc Worrell> :-) have fun reading. And editing!
[20:13:11] Arjan joins the room
[20:57:39] protagores leaves the room
[21:05:26] <Arjan> is the term "cache validation" or "cache invalidation"?
[21:06:00] <Andreas Stenius> depends on the action your performing, isn't ?
[21:06:38] <Andreas Stenius> I'd say the cache gc process does cache invalidation, where as a lookup does cache validation...
[21:07:10] Andreas Stenius goes afk...
[22:01:18] Arjan leaves the room
[22:03:31] Arjan joins the room
[22:07:16] Andreas Stenius leaves the room
[22:10:24] Andreas Stenius joins the room
[22:13:05] Arjan leaves the room
[22:37:02] Arjan joins the room
[23:21:52] Andreas Stenius leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!