Since we’re currently between sprints, the last week has been spent in picking up some leftovers from the previous sprint and preparing for the upcoming one.
We had some bugs and low-hanging optimisations that were ironed out in the last couple of days which as Spandan mentioned in his recent post has culminated in being able to start testing the client properly, i.e. against a distributed network of vaults rather than against a fake network.
We still have a lot of work to do to make this all more robust, but this represents decent progress.
We have several proposed RFCs which are being discussed in-house at the moment in preparation for the forthcoming sprint. I encourage everyone to have a peek and please add comments if you have opinions or questions about any of these. They represent a large part of the work scheduled for the next sprint, and planning for this sprint is under way at the moment,so get your thoughts and ideas in quick!
Having said that, nothing is set in stone, and these RFCs are mainly seen as initial efforts to implement basic, working functionality. We fully expect these to be built upon and advanced over the coming months and years. Please feel free to add your own RFC into the mix too.
As usual, here is the transcript of our Monday catchup meeting.
I think this is good old Scottish modesty at work . FYI…we’ll be publishing a blog post tomorrow that will hopefully summarise and tie together the last few months of dev updates. Please keep and eye out for it.
From the transcript:
Raspberry pi – testing applications for distributed environment
Forum software for distributed forum
Those snook in quetly… Daniel, please show us the architectures you’re using! Pointer to a repo would be great, explanation would be heaven.
Big question: are these using NFS API, REST API, or something else?
The Client example is using the REST API.
Thanks @fraser, I knew that, sorry I wasn’t clear. I’ve been hankering after help with how to build apps such as a CMS, blog with comments, and the “distributed forum” would I expect fit those kind of design patterns. But haven’t found anything yet, nor had my questions answered. This goes back a while now, which I understand as you guys have been a bit busy I hear :-), but if you are now working on such, sharing what you can to answer these questions would be eagerly consumed by quite a few of us, not just by me.
Sorry @happybeing - I didn’t really get your original question. I think it’s probably worth waiting just a wee while longer. We’re hoping to pick off many if not all of the items listed under Dev Bundle 2 in the forthcoming sprint.
We’ll need to finish the planning phase before seeing if these targets are all achievable within the sprint, but either way, it’ll all be happening soon. As far as I know, any targets which don’t get completed during the sprint become high priority for the subsequent one.
The relevant parts of Dev Bundle 2 are the last two bullet points: “App LauncherSample” and “UI based Apps commence”.
These will really be the point at which things should start to become easy to write your own apps. The launcher will hide much of the required details of authenticating onto the network, and clearly example apps should provide a good point of reference to begin your own work.
Up until this point, probably your best place to look is
rest_api example - it’s not bad for a sneak peek. But the outcome of the proposed RFCs I mentioned in my original post could change some of the details you see there.
Thanks @fraser, I’ve already absorbed all of those and been examining the examples, the API and how the API operates, and have been delving into architectural designs for web apps such as CMS, blog etc. Its as a result of this that I keep coming back to the same questions. What I don’t understand is what would be sensible ways to implement multi-user data access: e.g. posting a comment to a blog, when there is no server to receive the comment.
I thought how that would work was still out on the horizon, but this week’s transcript seems to say Daniel is working on a distributed forum app, which would have to deal with this issue, so I’m hopeful that he’s got an architecture, or a design specification, or some code, that can start to show me how we’re supposed to build this kind of system.
EDIT: for answers see Ways To Implement Shared Data Distributed Apps (e.g. multi-user blog etc.)
I suspect the messaging component will be key here. Whether it contains the payload or just an address to it, it would seem like an ideal way to announce a data state change to other parties.
I am interested to hear what is recommended on this too.
Woo hoo, thank you @dirvine. I guessed you had your reasons and … you’ve set a precedent now
I moved 2 posts to a new topic: Ways To Implement Shared Data Distributed Apps (e.g. multi-user blog etc.)
I also foresee that the messaging infrastructure is ideally suited. It allows anyone to add content to public data, at their own expenses. As such it is designed to reduce spamming, as the sender, not the receiver bears the cost.