Jan-Carel Brand talks about instant messaging and real-time functionality with XMPP and backbone.js, at the Plone conference 2012.

This is about real-time, collaborative applications in Plone. The obvious example is instant messaging. The roots of XMPP are in there, especially Jabber. You can with XMPP have voice and video conferencing. There is an extension for that: jingle. You can use that to tranfer any data, so sending files to another. You can do feeds and notifications, with a publication/subscription (PubSub) setup. Collaborative editing is possible and that is what blew me away.

collective.xmpp.chat is a chat client. See the code on github: https://github.com/collective/collective.xmpp.chat

There is hardly anything that actually accesses the Plone server during the chatting. We only get the full name, otherwise you could keep chatting even when the server is down.

Building blocks are:

• An XMPP Server and connection manager. Your browser makes a connection to the connection manager. Recommended is ejabberd, written in Erlang, which seems like a good language to use for this.
• Nginx or Apache does the reverse proxy for the connection manager.
• Plone add-ons:
  • collective.xmpp.core maps your Plone users to XMPP users. Thanks to Yiorgis Gozadinos for this!
  • collective.xmpp.collaboration
  • collective.xmpp.chat
  • collective.xmpp.pubsub

How does XMPP work?

• It is the eXtensible Messaging and Presence Protocol
• You need a Universal Unique Identifier (JID), like jcbrand@jabber.plone.org/sprint
• Some data exchanged as XML stanzas: presence (status), messages, information or query.
• A roster and a social graph: list/graph of contacts.

Stroph.js is your XMPP library for connecting to the server. It connects via BOSH to the XMPP server. You can add handlers for the stanzas with this or build your own stanzas. There are several plugins for it.

Backbone.js enables structured Javascript. You use this for example to show a chat box. The models have key/value bindings, custom events when a model has changed. You have a collection of models. Views: declarative event handling, templates (from underscore.js). Sync it with JSON if needed, like if you want to save the conversations in Plone.

I want everyone to be excited about what we can do real-time in Plone. Some ideas, with some that are already available:

• Messaging:
  • multi/single user chat
  • file sharing
• Collaboration:
  • documents, whiteborads, UML, mind maps
  • translations
  • pair programming in the Plone IDE or the Theme Editor
• Continuous feedback:
  • system status messages
  • user feeds (twitter inside your intranet)
• Audio or video conferencing

My website http://opkode.com

There is a buildout on github that you can clone:

https://github.com/collective/collective.xmpp.buildout

Ask me during the sprint if you want some assistence setting this up.

Martijn Faassen talks about Obviel, a client-side web framework, during the Plone conference 2012.

I am Martijn Faassen. I have a company called Startifact, doing freelance work. We may know me from Formulator, Five, lxml, Grok, Fanstatic and Silva. You should use Silva CMS, not Plone, so I will talk about that now instead of Javascript. Well, okay, if you insist I will talk about Javascript.

Comparison in Javascript can have unexpected, or at least unpythonic results. Javascript is like badly broken Python, which is a compliment for Javascript.

Obviel can be used to build web applications. It runs on the client side. It is best used on a page that needs to be updated all the time. It helps you exploit 'modern' browser features like CSS, the DOM and AJAX.

What does a web framework need? What do they almost all have? Templates. Sometimes they think this is all you need (php). I have not written a server side template for years, only client side. Obviel is a template implementation. Obviel first used JSON-Template, but there was no i18n support and other things could be nicer too. With Obviel Template and JSON you get rendered HTML. The template language is minimalistic and logic-less.

{variable2}
foo
{name}

Rendering into the DOM:

$(el).render(obj)

Obviel somehow finds the template belonging to an object. Each obj should have an iface property. It is just a string. Templates are associated with ifaces too. You declare a view with obviel.view.

Obviel = OBject + VIew + ELement

What changes? The server doesn't need to do the work of rendering. The clients do that for you. The templates tend to be small snippets that can be rendered individually. Obviel Template is not text-based, but DOM-based. It directly manipulates the DOM. The effect is the same.

{name}

You define evenOdd as a javascript function in the view.

Click here!

clicked is again a javascript function you define to do nice things.

@. is the current list element. Here we use the view of that element:

i18n:

This will be translated
The starship .

In the i18n we can have pluralization:

  There is {amount} light!
  ||
  There are {amount} lights!

obviel.i18n is gettext based. You can use Babel to extract strings. Also works for Javascript using jsgettext. It works, has features and is documented.

Routing on the client side. Browser has history, links, back button. Hard to do on a single page, but we still want to support it. There is the url fragment hack, like http://example.org/app#state. Or use the HTML5 history API to directly manipulate the URL. The application state can be a path, like app/animals or app/animals/djangopony. The path points to view and/or model.

Thesis, antitheses and synthesis. Thesis is traversal, its antithesis is routing, the synthesis is traject, hopefully the best of both worlds. We use that. Traject has a Python implementation, so you should look into it for the server as well.

Join us. See http://obviel.org

Oh, I have created a form library for Obviel, otherwise it would not be a web framework. obviel.forms. Since it is client side, a round-trip for validation is not needed. You do not post multipart/form data to the server, just JSON. This is much nicer for nested and repeated fields.

It is extensively documented, did I mention that?

Oh, we have obviel.sync under development. Goal: keep a set of client-side models in sync with a backend, like ZODB or a relational database. The idea is that the backends are pluggable: HTTP/REST, websockets, localstorage. Your model and view code do not need to know about the backend details. You mark changes in a session and commit it. You configure declaratively how the backend is used. Automatically send events when models change, so the UI can be updated.

It fits your Plone brain already. It needs more users. It works on IE8, I do not guarantee it for earlier versions of IE.

Jan-Jaap Driessen talks about fanstatic: handling javascript and css with ease, at the Plone conference 2012.

Loading resources (CSS and javascript) correctly and quickly can be hard. Which resources are needed on a specific page? How can you cache them correctly? You often get too many resources.

I see myself writing more and more javascript. Wouldn't it be cool if we treat our javascript, css, images as components, not just as simple files. Make them installable, give them dependency management. Collect them, load only the ones you really need. You can now easy_install about eighty js.* packages. Using entry points they know about each other. from js.jquery import jquery.

# Import a fanstatic resource:
from mypackage import my_email_validator

class MyWidget:
    ...
    # Make sure it gets loaded.
    my_email_validator.need()

You get flexibility of where and how to load the resource: put it at the top or bottom, maybe inserts the contents.

You can offload the work from the application server. Use WSGI to put this earlier in the pipeline and serve the files from the filesystem.

It is now zope "free". It has deep history in zope though, like hurry.resource. You can use it in grok, zope3, pyramid, django, webcore.

We have some bonuses:

• modes: give me the debug mode or give me the minified mode.

• caching: development versus production. You get a unique string for the datetime or with an md5 hash so caching can be done very strict.

• you can bundle resources:

  fanstatic/mypackage/:bundle:my-email-validator.js;my-password-helper.js
  

  Watch out for relative paths in your css though.

• You can also tell fanstatic to use a static server on a different domain, like static.example.org.

If you look at the performance guidelines from yahoo, a lot of stuff is already done by fanstatic.

Matthew Wilkes talks about performance for product developers during the Plone conference 2012.

I do performance and security work at the Code Distillery. Member of security team.

About performance. Plone is pretty fast. Low edit sites are really easy to make fly. It runs fine on a 256 MB VM. plone.app.caching takes about five minutes to configure. Add varnish and it goes really rather quick. Performance when logged in is harder. So site admins and integrators have it rather easy.

But what about product developers? No one of you deliberately writes bad, non-secure, non-performant code.

Do not add things to the catalog if you can help it. The catalog is already really big. An Archetypes object takes up less memory than a brain usually. If you have to, then use an indexer, not just a FieldIndex. This means you do not get a value for content types that do not have the field.

Build your types on dexterity, not Archetypes. Dexterity is the best thing Martin Aspeli has written. If you are doing some more low level things, use an OOBTree.

Keep Lengths of things that you need, instead of iterating over everything just to know how many things are in a list. Find a balance between huge objects and annotation soup. The more annotations you have, the less times you are going to write large objects to the database, but it takes more time to get the complete object with everything in it.

A for loop within a for loop is probably not a good way. Rethink this. Do not forget sets and itertools, they are good.

We have some tools available in Plone.

• Define cache:ruleset in zcml for custom browser views. You can go from, in an example, 79 to 0 milliseconds with a cache ruleset. You can directly assign rules to contexts by interface. You can map to an operation, like strongCaching, or to a ruleset, like plone.content.itemView.
• Hey, integrators: get write access to the Plone collective today and add rulesets to your favorite products. I will bring "I cleaned up your mess" stickers to Brasilia.

Edge Side Includes (ESI). Varnish is your friend. It lets integrators do page composition, but it is easy to leak data, so you need to be careful. With ESI you can arrange that the basic content of a page gets cached and the few spots that are not so static (say the navigation portlet), are included dynamically. In the cache rules you can set ETags to roles|lastModified, but ETags can be faked, so a malicious user can fake a Manager role. So integrators will need to segment their cache manually, which is hard work. But it can be done, or maybe it is not a problem on your site. It is a lot easier if add-ons are written with this in mind. So plan your templates for eventual ESIs. Using many small templates is appropriate, this lets them be cached seperately. If there is a block of mostly static html, make sure the user-specific bit is separated out. It should just take a few minutes.

You must test your caching, also automatically. Get a browser view in a test, then get it again and check that it is the same and Zope has only served it once. If you have plone.app.testing based tests, it is easyish. Create a new layer using a ZServer and start up Varnish. Make some testbrowser calls. Probably about half an hour or an hour to set up if you have the basis set up and are used to it. We need helper classes and methods for writing caching tests. We need actual tests in popular packages so we can point to them as examples. Tests in core Plone would be good too.

The current plone.app.caching rulesets are integrator focused. We need some standard ones for product developers to use. We should create some more standard rules for everyone, instead of everyone writing there own. So these are some sprint topics.

Read the documentation of plone.app.caching and certainly what is shown in the UI in the control panel. It can really help you.

Want help putting this into practice? Contact http://thedistillery.eu/

Lightning talks on Thursday during the Plone conference 2012.

IFoo(a)
IFoo(a, b)
IFoo(a, default=default)
IFoo.component(a)