question: version migration guide about golongpoll HOT 2 CLOSED

Hello, thanks for using it!

As far as (1) migration guide, going from v1.1.0 to current (v1.3.0) should be fairly straightforward.

Many of the changes have been additive, for example:

• Added an official Golang Client for making it easy to consume published events.
• Similarly, there's a javascript client. Admittedly it's not very modern javascript and I should make a fancier one with promises and whatnot...
• Added LongpollManager.PublishHandler as a counterpart to LongpollManager.SubscriptionHandler. One can serve that http handler to provide a default publish hook, or serve it with wrapping code/logic to add things like authentication.
• Documented the HTTP API
  • There is a new, optional param: last_id. As well as a new pubilsh handler exposed by LongpollManager.PublishHandler
• New examples showcasing some of the newer features.
• Added Options.AddOn which can be used to extend the longpoll manager's behavior.
  • The AddOn interface is defined here.
  • An example implementation is the included FilePersistorAddOn. See it's unit tests or an example usage. This AddOn enables published events to persist to disk--they won't clear across program restarts as without this AddOn they are only stored in memory..

In v1.1.0 these functions were deprecate: CreateManager and CreateCustomManager, and have been removed in v1.3.0. One should be using golongpoll.StartLongpoll instead.

So as long as you weren't using the already deprecated functions, and as long as you don't care about #19, I believe you should be able to upgrade versions and continue to use as you were.

If this is not the case and there are compiler errors after upgrading, I can certainly walk you through how to resolve any issues. That'd be a great way to come up with a migration guide if I'm wrong on this and there are actual changes needed.

If you care about #19, which would be the case if you have multiple calls to Publish() in the same function or otherwise call Publish() multiple times on the same category within the same millisecond, then you'd want to take advantage of the optional last_id param that has been added to the Documented the HTTP API. This is used to ensure no events are skipped when more than one is published on the same category within the same millisecond.

Instead of updating any of your go or javascript clients that are consuming longpoll events, you could take advantage of the official ones mentioned above in the list of new changes. Otherwise, the HTTP API docs should be able to walk you through how to call with the last_id param. If you were to upgrade from v1.1.0 to v1.3.0 and not update any client code to use the last_id param in subscription requests, things should still work as they did before, including the buggy behavior from #19.

As for (2): How to get a list of all currently active categories?

I assume you mean "active" as in the category exists/has had at least one event published on it. Perhaps excluding any category that is empty from Options.EventTimeToLiveSeconds clearing out events past the TTL.

The map/data struct that contains category data is not public, so there's no direct access to it. However, one could make a custom AddOn that can keep track of which categories are used/active. I would lean toward this approach versus adding a function to the LongpollManager that returns a copy of the current active categories (which would be a copy of the keys in a private map that the manager uses).

I will attempt to psuedo code what this would look like below. In fact, I do something similar with a LastEventPerCategoryAddOn in a chat webapp. That example wraps the FilePersistorAddOn to save events to disk, and adds tracking of the last event (chat msg) per category (chat room).

So to keep track of "active" categories, a custom AddOn would look something like:

import (
        // ...
	cmap "github.com/orcaman/concurrent-map"
)


// Keeps track of last event publish time per category.
type ActiveCategoriesAddOn struct {
	LastEventTimePerCategory cmap.ConcurrentMap
}

func (a *ActiveCategoriesAddOn) OnPublish(event *golongpoll.Event) {
        // Keep track of last publsih timestamp per category
	a.LastEventTimePerCategory.Set(event.Category, event.Timestamp)
}

func (a *ActiveCategoriesAddOn) OnShutdown() {
    // No custom behavior to add--but need to implement the interface.
    return
}

func (a *ActiveCategoriesAddOn) OnLongpollStart() <-chan *golongpoll.Event {
        // No custom behavior to add--but need to implement the interface.
	trivial := make(chan *Event)
	close(trivial)
	return trivial
}

Then you would include said AddOn in your function call that creates the longpoll manager:

	activeCategoriesAddOn := ActiveCategoriesAddOn{
		LastEventTimePerCategory: cmap.New(),
	}

	manager, err := golongpoll.StartLongpoll(golongpoll.Options{
		AddOn:              &activeCategoriesAddOn,
	})

One could then add a function to ActiveCategoriesAddOn that returns all categories that have a last publish time within a certain time range--for example: all categories whose last event timestamp is within now - Options.EventTimeToLiveSeconds.
One would have to look at the concurrent-map usage, on how to get the list of keys, or to iterate over all key/values and build up a returned list only including categories that have a last-event-time within the desired time range.

BIG FAT DISCLAIMER: I have not tried compiling the above snippets. And everything in this post is going off of memory as I have not touched any library code in over 4 months, and I am tired.

from golongpoll.

Thanks for this beautiful explanation

from golongpoll.