The QoS message option of calls is not passed. This causes calls from workers to get lost during reconnects.

There are a couple of changes needed to make cotonic work on IE11. (Run tests with browserstack)

• no startsWith available.
• no codePointAt available.

Maybe other things need to be added to the polyfills.

Or @mworrell, should we remove the polyfills from the base cotonic script and tell people to load it separately when needed (somebody uses IE11)? We could check if the required features exist, when they do not, inject a script with the required polyfills.

There are some failing tests in the broker test suite. It looks like because of small api changes.

The lifecycle model currently uses the unload event event to check if the page is terminated or frozen.

Lighthouse issues a warning against its used because it can influence the back/forward cache of the page.

It could easily be that it is no longer needed to use the unload event.

It must be possible to have back and forward functionality (with defaults, for when there is no history yet)

• model/location/post/back A href attribute can serve as default, or the default can be passed in the message.
• model/location/post/forward A href attribute can serve as default, or the default can be passed in the message.

Example:

<a data-onclick-topic="model/location/post/back" href="/home">Back</a>

It would be handy to make it possible to let parts of the dom-tree be managed by external libraries.

This is required to integrate tinymce in the admin pages.

Or to have externally managed logon buttons in the logon screen. For instance for Sign in with Apple or Sign in with Google, where the contents of a div is managed by another library.

https://github.com/cotonic/cotonic/blob/master/src/cotonic.ui.js#L221

There are some errors in the localStorage test suite. It looks like because of small api changes.

When link tags are inserted in the dom tree, special attention has to be given to href attributes.

When you insert a link tag, the href attribute has to be the last attribute added.

The reason for this is that the browser will interpret the resource as a css file because it does not know what the rel tag will be. It could easily be another type of resource.

cotonic.broker.subscribe("a/test", function(msg) { console.log(msg) })
cotonic.broker.subscribe("b/test", function(msg) { console.log(msg) })
cotonic.broker.match("+/test");
=> []

This should return the two subscriptions. Returning exact matches works.

Hi!

I'm planning to implement a UI selector using the document.querySelector (returns the first match) and document.querySelectorAll (returns all) instead of just by elems Id.
This adds the possibility to select elements by class, tags and also combined selectors.
Maybe the topic should be model/ui/q-insert/+key and model/ui/qall-insert/+key or something like that.
The selectors are very powerful, but the tradeoff is performance.
See some examples here.
How about?

I'm trying to use cotonic with vuejs, there is a problem with calling the call method, it does not work in mounted, it crashes all the time with a timeout
but if I make a button and load through it, then everything works out well
maybe there is unobvious behavior?
cotonic.broker.call("bridge/origin/model/amiro/post/list", {schema :'glossary', table : 'teducationalorganization'}, { qos: 1 }) .then(data => { this.items = data.payload.result this.totalItems = data.payload.length this.loading = false } ) .catch( error => {// all problem this.loading = false; });
Error: Timeout waiting for response on bridge/origin/model/amiro/post/list

It looks like a simple undefined -> null mixup for the packet_id

When you have html like there is no message published when the user clicks on the camera image.

<button class="btn btn-outline-dark me-2" data-onclick-topic="model/chat/add-image">
    <i class="fas fa-camera"></I>
</button>

In some situations it is possible that the on_depends_provided callback is called before the on_connect callback/promise is called. This can cause initialisation problems in worker code.

@mworrell The postMessage api is asynchronous as well, so you don't get responses directly.

We should probably add some mqtt protocol features like a connect (probably with keep-alive timer from mqtt-sn)/connack/disconnect messages with a will. That way the workers can find out if the page responds.

We probably also need pingreq and pingresp messages from mqtt-sn because there is no way for a worker or the page to find out if the worker is still running.

Rationale

It is sometimes needed to know the pages is connected again. Knowing that makes it possible to query the server for updates.

Proposal

Introduce two session events which are published when a transport has first setup the connection. (Before the CONNECT message is sent).

• session/+name/event/transport-connected
• session/+name/event/transport-disconnected

Usage example:

In Zotonic the event could be used to trigger reloads when the page reconnects and important elements have to be updated.

{% live template="_follower_count.tpl" 
        id=id
        topic=id
        topic={subject id=id predicate="is_following"}
        topic="session/origin/event/transport-connected"
%}

We currently have a very simplistic build process. The modules are concatenated with cat.

Eventually, cotonic has to be published on npm. In order to do that it would be nice to use a commonly used js bundler.

I try to use cotonic as MQTT client instead of mqtt.js
But currently I can't find how to connect to EMQ X broker.

There is a test EMQ X broker available https://www.emqx.io/mqtt/public-mqtt5-broker

I try to connect to it using

cotonic.mqtt_bridge.newBridge("broker.emqx.io:8083",
                              {protocol: "ws", controller_path:"/mqtt"});

It throws error
Error during WebSocket handshake: Unexpected response code: 400
According to doc: https://docs.emqx.io/en/broker/latest/advanced/http-api.html#response-code
400 - Invalid client request, such as wrong request body or parameters

I've tested broker using http://tools.emqx.io/ and it works, it means that problem is in snippet above, but can't understand what's wrong with that conntection.

We need to decide how to handle retained messages on bridged topics.

Problem is that they could be retained on the server and the client.
This might give duplication of information and duplication of messages.

Though it is also useful when the client is in offline mode.

• retain handling of bridge topics
• retain flags on published messages, should conform to subscription retain_as_published

IE11 is no longer supported, and its usage is very low.

I think the polyfill code can be removed. What do you thing @mworrell?

tell me how to enable cotonic in vuejs ?
I am writing an application in vuejs and I have included cotonic in vuex , everything works, but I do not understand how to include the library through vuejs

• Add docs. Release 1.0.5...1.0.6 adds the possibility to get and set cookies, but there is no documentation about that;
• Cookie delete topic;
• More payload properties: { secure: boolean, http_only: boolean, same_site: "none" | "strict" | "lax", max_age: integer (seconds), path: string };
• Change exdays to expires and, instead of days/integer, be a string value. Expires it's a kind of deprecated property, max_age (seconds) is preferred.

FYI

• Get topic: model/document/get/cookie/+key
• Set topic: model/document/post/cookie/+key
  • Payload: { value: string, exdays: integer }

function setCookie(cname, cvalue, exdays) {
        var d = new Date();
        d.setTime(d.getTime() + (exdays * 24 * 60 * 60 * 1000));
        var expires = "expires="+d.toUTCString();
        document.cookie = cname + "=" + cvalue + "; " + expires + "; path=/; Secure; SameSite=None";
}

Cotonic should not place inline event handlers and script tags on the page.

The navigator object has some nice api's attached to it. One of them is the share api. This makes it possible to open the device's native share window. Enabling this makes it possible to use it in a declarative way in templates. Or use it from workers.

Example:

<a href="#" data-onclick-topic="model/navigator/post/share">Share</a>

Only allow server to client publish on public/# and reply/# topics (pending identity checks on signed publish packets)

Cotonic currently automatically starts a service worker when the service worker api is available. It then registers it from /cotonic-service-worker.js.

This is problematic for two reasons:

• When cotonic is loaded from an external domain. In that case it is not allowed to start service workers.
• We also want to be able to use zotonic's static file caching mechanism,
• or be able to use an entirely different service worker implementation.

In order to support this I would like to be able to configure cotonic's service worker behaviour from a set of data-attributes.

• data-cotonic-service-worker-disabled - Don't register a service worker.
• data-cotonic-service-worker-src - Use the specified service worker src uri.

Question:

Where do we place the attributes?

• Do we define a specific location (html, head, body) for the data attributes,
• or use querySelector("[data-cotonic-service-worker-src]") which allows it to be placed anywhere on the page.
• or from the script tag from which cotonic is loaded.

The middle option is th e

Examples:

The examples assume the the attributes are placed in the script tag from which cotonic is loaded

Disable the service worker::

<html>
...
<body >
    <script src="cotonic.js" data-cotonic-service-worker-disable></script>
</body>
</html>

Or load a specific service worker in a template.

<html>
    <head>
    </head>
    <body>
        <script src="cotonic.js"
                     data-cotonic-service-worker-src="/lib-min/cotonic-service-worker~1312361.js"></script>
    </body>
</html>

This will speed up tokenizing charrefs considerably. Especially because the same piece of text with the same charref will be tokenized multiple times during its lifetime.

We currently request animationFrames in a tight loop. Even when there are no updates. This wastes resources. When there are no dom updates, we should not request animation frames.

The current Makefile should be used by gmake.

The default make on (for example) FreeBSD can't process this file.

This can be fixed by using a GNUmakefile and use gmake to process it.

See also zotonic/zotonic#2175, as reported by @seannaswell

We currently use a slightly older version of incrementalDOM. Check if we can upgrade.

The MQTT session is decoupled from the bridge and can be made into an independent web worker.