[openspending-dev] Alternative architecture diagram

Mon Jan 5 22:55:06 UTC 2015

Hey,

> On 6 Jan 2015, at 09:02, Friedrich Lindenberg <friedrich at pudo.org> wrote:
> 
> Thanks for the feedback, Paul! I'll admit I was pushing it on "Others", trying to make this point: we can reduce the total amount of functionality that the OS team has to maintain by extensively basing the work on external/existing libraries, specifically: 
> 
> On Mon, Jan 5, 2015 at 10:53 PM, Paul Walsh <paulywalsh at gmail.com <mailto:paulywalsh at gmail.com>> wrote:
> E.g.: relational db,
> 
> Postgres :)
>  
>  
> resource repository
> 
> S3, Archive.org, ...
>  
> and analytics api
> 
> http://pythonhosted.org/cubes/recipes/flask_integration.html <http://pythonhosted.org/cubes/recipes/flask_integration.html>
> 
> I'm wondering if you are using the colour coding with a different meaning to that of OSEP1/2.
> 
> Yeah, I skipped the "may need some duct tape" warning :) 

Well ok then, so I see where you are coming from. I understood “others” in OSEP1/2 to mean something rather different, i.e., stuff not in the core. You are using it to mean stuff in core that is dependancy code/platforms.

>  
> It also looks to me that this is not really an alternative to OSEP1/2 as such, and rather a view of it from a different perspective. For example, this diagram is more concerned  with the stack (angular, cubes, loadkit, s3, etc) than the design itself, as I read it.
> 
> Well, the design is that there's an app, OpenSpending, and it provides cool spending data APIs.
> 
> This is the conservative counter-proposal to the OSEP1/2 model of splitting it up into a set of smaller web applications written in different programming languages which would interact via a mix of APIs and static file dumps. At least that had been my understanding of the proposal after my conversation with Rufus yesterday.

Ok. I think emphasising different programming languages makes it seem more radical than it is. The main takeaway I have from Trygvvi's and Rufus’ diagrams, and from discussions, is the slimming of the core and externalising some services so that they can grow without enforced dependency.

>  
>  
> Just adding these comments now as I'll be traveling around the world while the meetings are on tomorrow.
> 
> You're in luck, I think the public developer meeting is Thursday!

I have a (very) long trip.

>  
> 
> - Friedrich 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending-dev/attachments/20150106/dd604c7c/attachment-0002.html>