Wednesday, 7 November 2012< ^ >
arjan has set the subject to: Zotonic - the Erlang Content Management Framework
Room Configuration

[06:56:31] arjan joins the room
[08:22:18] arjan leaves the room
[08:23:20] maas.maarten.zeeman joins the room
[08:29:38] <maas.maarten.zeeman> Nog niet geprobeerd, maar dat blijft gewoon een multipart upload die de postback controller kan parsen.
[08:30:08] <maas.maarten.zeeman> Ow sorry, english here.
[08:39:29] <maas.maarten.zeeman> When the data is coming from a form, you have string only value's anyway.
[08:39:56] <maas.maarten.zeeman> It required quite some searching to find out what part of zotonic is doing what.
[08:41:40] <maas.maarten.zeeman> z_context:require_qs will always be parsing form-urlencoded and multipart requests
[08:47:28] arjan joins the room
[08:48:29] <maas.maarten.zeeman> So file uploads are left as they are. Different postback encoding are only useful for z_event, z_notify with extraParams. Then th
[08:48:54] <maas.maarten.zeeman> file uploads don't have an extra params option,
[08:51:54] <maas.maarten.zeeman> hmm not so sure as i look at postbackfileform in zotonic-1.0.js right now.
[08:55:01] <maas.maarten.zeeman> validations travel as extra params
[09:00:32] <maas.maarten.zeeman> btw. it is possible to change z_init_postback_forms. It is possible to use $(document).on("click.form-plugin", "form[action*='postback']", ....) before the form is placed on the page. That is also handy form popups with forms.
[09:02:55] <maas.maarten.zeeman> tricky stuff.
[09:16:01] <maas.maarten.zeeman> File uploads travel via a dynamically added iform any extra params are attached via hidden form field. That should work as i left the normal processing in place.
[09:16:23] <maas.maarten.zeeman> There is one gotcha though. The extra params (validations) will be a proplist with string only.
[09:23:20] <maas.maarten.zeeman> Hmm, jumping on rowingbike to work to think this over a little bit. Don't know if it is a good idea to complicate postbacks more than they already are.
[09:24:31] maas.maarten.zeeman leaves the room
[10:28:07] maas.maarten.zeeman joins the room
[10:50:51] <maas.maarten.zeeman> Maybe it is easier to a new way of communicating with zotonic.
[10:51:12] <maas.maarten.zeeman> Than bolting something on an existing way.
[10:52:31] <arjan> makes sense to me
[10:54:41] <maas.maarten.zeeman> That will just be a new controller and maybe something which allows one to send different data over an existing websocket.
[10:55:55] <maas.maarten.zeeman> + a js api to use it.
[10:56:40] <arjan> sounds good!
[11:03:02] <maas.maarten.zeeman> Now the websocket controller hands over the postback data to controller_postback, maybe we can structure that a little bit to allow other controllers to receive things via the open websocket.
[11:05:13] <arjan> that would be nice indeed
[11:05:59] <maas.maarten.zeeman> Looking back, basically that is what I needed.
[11:06:06] <arjan> :)
[11:11:56] <maas.maarten.zeeman> Maybe controller_websocket should call z_notifier:first({websocket_message, Msg}) or something.
[11:15:16] <arjan> yes
[11:15:18] <arjan> is Msg binary?
[11:15:24] <maas.maarten.zeeman> Yep
[11:15:29] <arjan> how would you match on that
[11:15:34] <arjan> intelligently
[11:19:06] <maas.maarten.zeeman> Ow right, can't you match on binary prefixes?
[11:20:08] <maas.maarten.zeeman> <<"postback=", _/binary>>
[11:20:27] <maas.maarten.zeeman> or not intellegent enough?
[11:22:32] <arjan> sure
[11:22:43] <arjan> if we prefix each message
[11:23:29] <maas.maarten.zeeman> That is the way it is done right now. It is the prefix of the query string which is send over the websocket
[11:23:35] <maas.maarten.zeeman> :-)
[11:24:02] <maas.maarten.zeeman> We could also add an extra parameter maybe...
[11:36:45] <maas.maarten.zeeman> Maybe we should package that in ubf format like this: {'postback'#{'qs' "postback=..rest_of_qs"}&}
[11:38:16] <maas.maarten.zeeman> and then parse it in controller websocket and call first({websocket_message, {postback, [{qs, "...."}]})
[11:46:01] <arjan> why not go for a completely free model?
[11:46:14] andreas.stenius leaves the room
[11:46:37] <maas.maarten.zeeman> What do you mean?
[11:46:38] <arjan> for instance <message type>#<payload in whatever format>
[11:46:57] <arjan> so you just match on the start of the message
[11:47:12] <arjan> and interpret the rest of the message however you want
[11:47:44] <arjan> e.g. Msg = "jsoncallback#[1,2,3]"
[11:48:02] <arjan> where module would match on <<"jsoncallback#", Payload/binary>>
[11:48:19] <arjan> and postback on <<"postback#", Postback/binary>>
[11:48:39] andreas.stenius joins the room
[11:48:47] <arjan> the prefix stuff would be a convention
[11:48:59] <arjan> but optional
[11:49:15] <arjan> that way you can reuse websocket_controller for other kinds of messages
[11:49:50] <arjan> websocket_controller doesnt assume anything about the message contents, just uses a z_notifier:first to deliver it
[11:50:10] <arjan> and the foo# convention is implemented by all our modules
[11:50:30] <maas.maarten.zeeman> Right, allowing all listeners to do whatever they want with the message. Better indeed
[11:50:49] <arjan> maybe you also need the current dispatch name in the notification
[11:50:59] <arjan> so you can make a custom websocket handler on a different URL
[11:51:23] <arjan> and intercept every message sent to the websocket on that url
[11:51:33] <arjan> but dont intercept other ws messages (e.g. normal postbacks)
[11:55:50] <arjan> makes sense?
[11:55:54] <maas.maarten.zeeman> Allowing one to setup multiple websockets.
[11:55:58] <arjan> yep
[11:56:49] <arjan> though there is still the question of how to send stuff back to those sockets
[11:56:58] <arjan> I like how cowboy does websockets
[11:57:44] <maas.maarten.zeeman> :-) z_session_page now supports either a comet or a websocket.
[11:58:17] <maas.maarten.zeeman> It is possible to link more processes though
[11:58:20] <arjan> true but what about custom connections
[11:58:23] <arjan> oh
[11:58:41] <arjan> how?
[11:59:02] <maas.maarten.zeeman> I see a call spawn_link in z_page_process
[12:00:11] <maas.maarten.zeeman> That would allow one to add non-standard comet style push websockets.
[12:02:29] <maas.maarten.zeeman> More complex to build though
[12:10:48] <maas.maarten.zeeman> Interesting idea. That would be nice to support websockets which send back something else than javascript.
[12:11:34] <maas.maarten.zeeman> Should be done in sync with a solution for comet style connectivity though as websockets still have many problems.
[12:23:33] <arjan> if we switch to cowboy we can use bullet
[12:25:52] <maas.maarten.zeeman> Aha, now I understand what you mean with adding the dispatch.
[12:26:50] <maas.maarten.zeeman> That are proper bi-directional streams
[12:28:04] <maas.maarten.zeeman> bullet.js contains nothing specific
[12:28:11] <maas.maarten.zeeman> for cowboy that is.
[12:29:23] <arjan> but it has a serverside component
[12:35:26] <maas.maarten.zeeman> I really like the abstraction. The server component part is basically a controller. I don't think that can be transferred to zotonic 1:1 but easily implementable though in current zotonic I think.
[12:36:31] <maas.maarten.zeeman> A "bullet" process can be attached to a page session
[12:37:48] <maas.maarten.zeeman> This process can then handle either normal http or websockets and maybe throw server sent events in the mix.
[12:39:09] <maas.maarten.zeeman> That is more generic than the current comet and websocket process.
[12:40:44] <maas.maarten.zeeman> Also with heartbeat, which is what we miss right now.
[12:43:36] <maas.maarten.zeeman> What we have right now with comet and websocket support and postbacks is basically what bullet is for cowboy. Only cowboy you can define custom bullets....
[12:44:06] <maas.maarten.zeeman> (Not entirely true, because sending files is not covered by bullet)
[12:45:34] <maas.maarten.zeeman> But this is exactly what I need right now as abstraction it is already usable...
[12:46:21] <maas.maarten.zeeman> wow
[12:51:50] <maas.maarten.zeeman> I f
[12:57:56] <maas.maarten.zeeman> Nice.
[13:19:53] <maas.maarten.zeeman> I think it can be implemented as a separate module for zotonic and integrated quite nicely. Eyeballing mod_logging which handles log updates.
[13:23:25] <maas.maarten.zeeman> It could add {admin_log_stream, ["admin", "log", "updates"], controller_stream, [{stream_handler, log_stream}]
[13:24:31] <maas.maarten.zeeman> with log stream being a process which listens to log update notifications.
[13:24:45] <maas.maarten.zeeman> Less magical than mod_signal
[13:28:17] <maas.maarten.zeeman> For log's it is output targetted page only
[14:01:12] <maas.maarten.zeeman> Thanks arjan. Working on a new zotonic module along the lines of bullet.
[14:02:01] <maas.maarten.zeeman> Changing postback formats and hacking controller websocket is not the way to go.
[14:14:12] <arjan> cool
[14:14:28] <arjan> I actually quite like cowboy
[14:14:41] <arjan> using it now for the web frontend for a spotify jukebox
[14:14:46] <arjan> (weekend project)
[14:14:47] <arjan> :p
[14:39:39] <maas.maarten.zeeman> Cool idea btw.
[15:21:26] andreas.stenius leaves the room
[15:54:42] Ilya Rezvov joins the room
[15:56:27] andreas.stenius joins the room
[16:23:58] <maas.maarten.zeeman> Is there a way to get the current dispatch name from the context?
[16:35:17] <arjan> in the tpl its called zotonic_dispatch
[16:35:25] <arjan> should be hding somewhere in the context...
[16:35:36] <maas.maarten.zeeman> :-) k
[16:38:29] <maas.maarten.zeeman> Yep, z_context:get(zotonic_dispatch, Context) does the trick. I can use that as a name of the persistent connection
[16:40:39] arjan leaves the room
[17:26:39] maas.maarten.zeeman leaves the room
[17:29:54] Ilya Rezvov leaves the room
[17:40:34] Ilya Rezvov joins the room
[17:57:03] Ilya Rezvov leaves the room
[18:11:43] arjan joins the room
[19:09:51] Ilya Rezvov joins the room
[20:30:12] arjan leaves the room
[20:46:06] arjan joins the room
[20:50:23] Maas joins the room
[22:25:03] arjan leaves the room
[22:42:13] Ilya Rezvov leaves the room
[23:45:36] andreas.stenius leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!