Separate tables for Events and RSVPs? about beaker-profiles-api HOT 4 OPEN

At first I thought, "but microformat references to things are all also URLs, and they mark their types anyway for ease of discoverability and parsing." Then I remembered, there aren't any third-party parsers in play here, just apps using the webdb API. Thanks for the help articulating a justification for my gut feelings! :-)

from beaker-profiles-api.

Yeah we probably won't implement those types in 0.8, but part of our post-0.8 plan is to expand the webdb types, and events + rsvps would be a good fit for that.

Related - Im thinking we 1) need to rename this repo to webdb, and then 2) put a /specs/active folder, plus a /specs/proposed folder. When I do that, I'll write some specs in markdown which you can copy from.

In the meantime, feel free to write out your thoughts for the schemas in this issue.

from beaker-profiles-api.

I tried rattling out schemas for these, basically cribbing from microformats, and only one thing struck me as really worth discussing: in microformats, an RSVP is just a field you attach to an h-entry - what webdb would call a post, in other words.

My instinct is that this kind of overloading of posts is something that you might as well do with conventional browsers, where everything is coming out of a freshly-parsed XML document every time anyway, but that doesn't make as much sense in this world where we're making something that more closely resembles a persistent database. If you're going to have posts with fundamentally different purposes, just put them in different tables and everybody will be happier in the long run... I think. Am I wrong?

from beaker-profiles-api.

I think so too. You're right that there's a generic pattern involved, but I dont think we gain anything by making one mega datatype that spans use-cases. We can just make an RSVPs table. Also- URLs are generic, so it should still be possible to create links between differing data types.

from beaker-profiles-api.