Something Other than ATOM

EventStoreDB
1

Just curious if using something other than ATOM has ever been considered or discussed.

ATOM just doesn’t feel like a good fit when working with it for event streams. It’s an “almost” fit - much like the way it is for many applications/tools/frameworks that it has been applied to as a matter of reuse rather than fit.

Working with ATOM for event streams succeeds on the level of complying with ATOM, but it seems like the kind of success we’d declare when making a square peg comply with a round hole.

It’s understandable that there are existing ATOM clients, but the EventStore data (especially when outside of XSD, as when JSON) doesn’t exactly line up with ATOM that well.

It would seem like an opportunity to create a schema specifically suited to event streams rather than only pursuing compliance with an existing standard from another domain. Perhaps that schema could be published separately, with EventStore even getting credit and credibility by association (kinda like the way GitHub is associated with semver through Tom Preston Werner).

Anyway… just a thought.

Best,

Scott

2

As a specific example - in the ES .NET Client, you map the ATOM field updated to created. Probably because that makes about 1000x more sense in a system that is so vigorously defended as write-only-no-update. Having that updated field at all probably confuses people more often than not…

Incidentally, in our client that we’re building, we’re mapping it to created_time, which is more expressive in our opinion than created but seems like needless extra work that was generated to comply with ATOM.

3

The .net client isn’t atom.

4

Perhaps the point goes to consistency, then - which may not be relevant for the product vision.

A lot of this goes to the cost of learning EventStore when the cognitive load is highest: at the beginning. That’s more a matter of a human factors issue. My expectations of what it’s supposed to be are biased to my assumptions, which could be way off-base.

Best,

Scott

5

Ultimately, the issue of whether the .NET client is ATOM or TCP isn’t the central thrust of the point I was making about ATOM and the upside of not complying with it.

Still curious if the matter had been a consideration…

Best,

Scott

6

This has come under consideration. See https://github.com/EventStore/EventStore/issues/424

7

I was referring to the other comment that was about the .net client which does not in any way use atom.

In terms of other protocols yes they have been considered including something custom say sse based. To be fair pure http 1.0/1.1 based it would look a lot like atom the interesting bits about atom are …

  1. look at cacheability of stuff (assuming public or at least trusted caches)

  2. look at content types and how they work eg post xml get json

  3. try opening an atom feed in say chrome (raw feed) chrome has a custom ui for it (all intermediaries basically understand atom)

Greg

8

Thanks, Greg.

Best,

Scott

9

There is actually a change that I will do in the next week or so
specifically to make this easier in the future. Adding a description
document at the root (also allows the competing consumer interface to
be there)

e.g. GET /streams/foo Accept: application/vnd.eventstore.streamdescription+json

return rel links + media types ...

10

Another good reason for going with Atom at the time was that almost every platform has at least one client library. The reason some of the fields don’t appear to make sense is that many of the parsers fail (some more reasonably than others) if a minimum set of fields is unavailable.

11

That’s probably a predictable outcome of an alomst-good-fit of an existing spec.

There was a time when ATOM didn’t exist, and then it came into being. Schema standards can be created. The existence of ATOM proves it (as does RSS, etc, etc).

I just think that something that is purpose-built will have less of the cognitive load that comes from mapping unnatural concepts from news media syndication on top of event streams.

This is the second system I’ve built that was entangled with ATOM, and it’s the second time I’ve affirmed my loathing for using it for anything other than a newspaper’s homepage - especially the reverse chronology stuff, the arbitrary changes to make it carry arbitrary data, the poor mapping of existing mandatory fields onto an unlike domain, etc.

I don’t see reuse as a goal in and of itself (if I did, I wouldn’t be building an EventStore client for my environment - I’d be force-fitting an almost-good-fit solution). Doubtless, there’s benefit to re-leveraging existing support for ATOM, and that can be ridden a long way.

I just think it’s time to start the process of moving on, and doing what the ATOM pioneers did when they got fed up with the arbitrary compliance with the RSS “channel” element. An inexact fit isn’t a negligible cost over time.

I think it can be better, and more understandable, and that moving people to the paradigm will be smoothened non-trivially by removing up-front cognitive obstacles and “huh? why is it like this?” moments.

Either way, I appreciate the work and the product. I do wish for more polish so that I could spread the work in my community more easily, and grow the pool of potential recruiting candidates, but I understand that that goal isn’t necessarily shared.

Best,

Scott

12

Does that mean that the competing consumer stuff will be supported by the HTTP interface?

Thanks,

Scott

13

Does that mean that the competing consumer stuff will be supported by the HTTP interface?

Yes - that work is on a branch and is almost complete.

14

Good stuff. I look forward to details about the protocol.

Best,

Scott

15

I just think that something that is purpose-built will have less of the cognitive load that comes from mapping unnatural concepts from news media syndication on top of event streams.

I actually don’t disagree that it might be worth looking at something else - it turns out that most of the atom parsers available simply aren’t very good anyway so that’s not necessarily a compelling reason to stick to Atom. There was some work being done around an event syndication format for reactive extensions for JS - that might serve as a starting point.

The timescales for that are more interesting though - it’s a significant chunk of work, though so is clearing up the Atom generation.

16

yes.