Microcosm Feature Suggestions

Does Event have somekind of superclass ListDriven?

OMG No! I feel dirty just reading that.

First, it's all written in Go and there are no classes, no inheritance, no objects, thus no superclasses as you might imagine or know them.

We have a load of REST interfaces, and these are mappable to URLs and internally some of these endpoints are smart enough to work against multiple parent URLs.

A great example is the attributes stuff: http://microcosm-cc.github.io/#attributes

That allows key:value pairs to be set against pretty much anything.

So you could stuff key:value pairs against a profile: rides = Cannondale, height = 185cm

Or against events: bike hire = available, min age = 18

Now getting back to lists, events has a concept of attendees. And this isn't just a flat list of arbitrary values, it's a list of usernames and only the individual attending or the event organiser can set these. So it's a list of users, with state showing attendance, and permissioned: http://microcosm-cc.github.io/#attendees

It's specialized as we imagine that it has specialized functions in future: Who's attending? I need to send a last minute update via SMS to all attendees, etc.

We could extend the idea of that to other REST endpoints, but at the moment it is a specialized list that serves one function: To indicate attendance of an event.

Now, going back to the question of "Can we add lists". I guess what I wanted to know was how they might be used, what should I bear in mind.

It looks like, from the initial feedback and bearing in mind how I've seen lists used on LFGSS, that you want:

1) The ability for any type of conversation/item to have a list.

2) That the list is made up of who added themselves, and optionally some value along side it.

It's quite likely that such a structure would allow us to implement event attendees in that form (we'd stick the attendance state in the value field), but I can't foresee that event attendees could be extended to that form.

Does that sound like the kind of thing you image... a list of users with an optional value next to the user.

As for the group purchase scenario, the rules around group purchase vary greatly and are usually dictated by suppliers. I can't imagine us being able to mimic the that stuff to any depth, whatever we'd do would be wrong for the vast majority of use-cases.

Some things are best done in a spreadsheet and I'd probably recommend that we just offer embedding of Google Docs.