search

exodusproject / spec

(Discussion of) specification of the procotol.
3 stars 0 forks source link

Module genericity #3

Closed arturovm closed 8 years ago

arturovm commented 8 years ago

This whole discussion spawned because @cphuntington97 wanted to know whether an RSVP functionality would be included in the social module, or whether it would be a different module. This got me thinking about what level of genericity we want modules to have.

Should modules dictate a fixed set of capabilities and expose a set of fixed APIs and only allow different UIs to be built around them? Or should they provide tools generic enough so that developers might build any app they want?

Taking the social module, for instance, should we decide what features we want in it (posts, follow/unfollow, RSVP, etc.)? Or should we instead make a feed module, where the module only provides a generic mechanism to subscribe to someone else's feed and it's up to developers to decide what sort of data they want in their apps?

bnb commented 8 years ago

Are you asking if we should build services (think Facebook, Twitter, GitHub, etc.) versus features (think follow/unfollow, posts feed, even posts)?

If so, I'm 100,000,000% in favor of modularizing features versus building hard services. The only issue I see with this is ensuring the needed modularized features are displayed or requested, but I think you were addressing this when you were discussing the SMTP handshake and signifying what is used at that point

arturovm commented 8 years ago

Not necessarily features vs services, but that's one way to think about it. The key here, is that right now we have the freedom to decide how generic or concrete we want our modules to be, and this is a decision that will influence the whole project in a tremendous way.

I like your approach. Perhaps a Twitter-like app would only make use of the text posts feature, while an Instagram-like app would make use of the photo posts feature only, etc.

That being said, this is still a very open discussion and we need as many ideas and input on this as we can get from our core team.

arturovm commented 8 years ago

An example of extreme genericity would be a module that exposes a REST API with endpoints that allow CRUD operations on any Resource. But obviously we don't want that, because then we would be essentially re-inventing the filesystem through HTTP, and that's… not good.

On the other end of the spectrum, we say, "Here. This is your social network. These are the features it will have. You can build an UI around it and make it pretty, but that's it, that's all you can do."

bnb commented 8 years ago

Duplicate of #1! We can finish there.