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.
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.
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.
I’ve sketched out what I think would be the best way to do this with the existing API, but it doesn’t seem viable really, so I’ve been hesitant to spend too much time going that way, and anticipating that there’s more to come. From time to time I’ve asked about this, trying to understand what might be coming and how we should design for it. David has said that the system will be like other NoSQL databases, but that would I think mean a more functional API than that for which we have any details so far. A long time ago he mentioned Redis so I looked at it briefly. Recently I’ve looked into CouchDB which has a RESTful NoSQL API. Both offer functions through the REST API that go much further than what we have now, so I assume more is planned, but I don’t know if or how the SAFE REST API will be extended towards these kinds of feature, or if the NFS API is the best way to go, or something else is coming etc. So my app plans are stalled really. I posted some early investigations and ideas on the forum, and think it would be quite easy to get some web apps (ie pure HTML & JavaScript) built based on exisitng CouchApps and similar, but need to know more about the API before I can go any further. The same questions will apply to native compiled apps, not just for web apps, so a few of us are eager and - sorry - one or two of us, ok, just me: pestering I’m feeling a bit sheepish about that, but when I saw this week’s transcript, it looked like the info I need might be available.
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.
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.
. 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.
