On Wed, Feb 4, 2015 at 6:59 AM, Marko Obrovac <[email protected]> wrote: > On Tue, Feb 3, 2015 at 8:42 PM, Tim Starling <[email protected]> > wrote: > >> I don't really understand why you want it to be integrated with >> RESTBase. As far as I can tell (it is hard to pin these things down), >> RESTBase is a revision storage backend and possibly a public API for >> that backend. > > > Actually, RESTBase's logic applies to the Mobile Apps case quite naturally. > When a page is fetched and transformed, it can be stored so that consequent > requests can simply retrieve the transformed document form storage. > >
Ok, so in this vision RESTBase is a caching layer for revisions >> I thought the idea of SOA was to separate concerns. >> Wouldn't monitoring, caching and authorization would be best done as a >> node.js library which RESTBase and other services use? >> > > Good point. Ideally, what we would need to do is provide the right tools to > developers to create services, which can then be placed "strategically" > around DCs (in cooperation with Ops, ofc). For v1, however, we plan to > provide only logical separation (to a certain extent) via modules which can > be dynamically loaded/unloaded from RESTBase. In return, RESTBase will > provide them with routing, monitoring, caching and authorisation out of the > box. The good point here is that this 'modularisation' eases the transition > to a more-decomposed orchestration SOA model. Going in that direction, > however, requires some prerequisites to be fulfilled, such as [1]. > So, now RESTBase has become a router and an auth provider as well? (Gabriel already clarified me that "monitoring" means that RESTbase will expose its own metrics for that specific service, so this is not monitoring of the service at all, rather accounting). I need some clarification at this point - what is RESTBase really going to do? I'm asking because when I read "RESTBase will provide them with routing, [...] and authorisation" I immediately think of a request router and a general on-wiki auth provider. And we already have both, and re-doing them in RESTBase would be plainly wrong. Maybe you intend very specific things when you say "routing" and not request routing, which is what everybody here will think of. And when you say "auth" you mean that RESTBase implements an auth schema for its clients, so that no client can access data from another one. If this is the case, I have some further questions: is this going to be RBAC? Which permissions models are you implementing? Are we sure it is what we will need? And foremost: will this be exposable to external consumers? will it be able to hook up to our traditional wiki auth scheme? Can you please expand a bit on those concepts? Or a lot of confusion, uncertainty and doubt will spread amongst your fellow engineers, resulting in an hostile view of what may be a perfectly well designed software. Cheers, Giuseppe _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
