Hey Chris,
I like hovercraft and it's simple and clean api to talk to couch. Are you
talking about clustering over RPC? I know way too little about couch to
mouth off like this, working my way to defining a structure for trees and
graphs in couch is keeping me busy enough.
Cheers
Suhail
On Sun, Nov 1, 2009 at 7:15 PM, Chris Anderson <jch...@apache.org> wrote:
> On Sun, Nov 1, 2009 at 11:00 AM, Suhail Ahmed <suhail...@gmail.com> wrote:
> > Hi,
> >
> > Any chance of seeing native erlang RPC protocol in 11 or soon there
> after?
> >
>
> This may be part of the Cloudant clustering codebase. I can't speak
> for them, but from what I've heard it does inter-node communication in
> a native Erlang way. You could probably use this interface as a
> primary client interface as well, but what do I know? :)
>
> Chris
>
> > Cheers
> > Suhail
> >
> > On Sun, Nov 1, 2009 at 6:48 PM, Chris Anderson <jch...@apache.org>
> wrote:
> >
> >> Thanks Benoit for the topic,
> >>
> >> I've got a wishlist for 0.11 / 1.0 - some of it I'd be game to
> >> implement, some of it I think others would be better suited for:
> >>
> >> Accounts tab in Futon
> >>
> >> Eventually we'll need something like /_utils but not for developers.
> >> For now we just need a page in Futon where you can login and out, as
> >> well as manage user accounts if you are an admin.
> >>
> >> Listable _changes
> >>
> >> If you could format the changes feed with a _list style API, you
> >> could use it to drive XMPP or other protocols. I'm keen on building a
> >> version of Toast chat that works even in browsers that have JS
> >> disabled. I have a feeling the only person who's gonna write this
> >> patch is me.
> >>
> >> couchjs security
> >>
> >> The couchjs process is currently "secure enough" for the context
> >> where only admins can modify design documents. However, as CouchDB
> >> spreads, we're sure to see misconfigured instances out there. Also,
> >> making the JS capabilities more controlled will definitely protect
> >> against some attacks in shared hosting environments. (Eg those where
> >> many users have private dbs on the same node.)
> >>
> >> Currently JS functions can hack the sandbox to make http requests
> >> via curl. We need this functionality for the test suite, but not for
> >> the design document OS process. So we should use a command line flag
> >> to --enable-http that the test runner can use.
> >>
> >> We can also be more secure in our ["reset"] handling. Because
> >> there's no such thing as a real JS sandbox, if we move our ["reset"]
> >> handling to C, and have it swap out the JS context for a new one,
> >> we'll avoid the case where databases on the same node can spy on each
> >> other, by say, overwriting the emit() function to also store important
> >> values for later playback to the attacker db. There could be some
> >> performance impacts of a C-based reset (as it would involve compiling
> >> all of main.js after each reset).
> >> An alternate way to implement this is just to stop recycling
> >> processes in Erlang, and through them out after each use. I think that
> >> will get expensive (but maybe not much worse than C-based reset). This
> >> is trivial patch if anyone needs to run extra securely in a
> >> shared-host environment today.
> >>
> >> cron / event / changes handler
> >>
> >> Applications need to be able to trigger functionality in a periodic
> >> or event-based way. We could probably piggyback on _changes heartbeat
> >> to provide cron + event services. The idea is a design document
> >> function ("event" or "cron" or maybe "trigger") that is called once
> >> for each item in the changes feed.
> >>
> >> This is the one I'm least sure about, but I've heard a lot of people
> >> request it. It's problematic because cron functionality isn't that
> >> useful unless it has side-effects, which brings the whole sandbox/http
> >> question up again.
> >>
> >> rewriter
> >>
> >> There's getting to be a pretty common pattern where people write
> >> CouchApps and then deploy them behind a rewrite proxy. We've already
> >> got rewrite patches floating around. It's just a matter of making the
> >> API decisions.
> >>
> >> clustering
> >>
> >> I've heard Cloudant has some clustering code, I'd definitely be
> >> willing to help with integration, and I'm sure there are other people
> >> who would as well.
> >>
> >>
> >> Cheers,
> >>
> >> Chris
> >>
> >>
> >> On Sun, Nov 1, 2009 at 7:02 AM, Benoit Chesneau <bchesn...@gmail.com>
> >> wrote:
> >> > was sent on user@ sorry for crossposting .
> >> >
> >> >
> >> > ---------- Forwarded message ----------
> >> > From: Benoit Chesneau <bchesn...@gmail.com>
> >> > Date: Sun, Nov 1, 2009 at 3:44 PM
> >> > Subject: roadmap 0.11/1.0
> >> > To: u...@couchdb.apache.org
> >> >
> >> >
> >> > Hi all,
> >> >
> >> > http://couchdb.apache.org/roadmap.html hasn't been updated. And in
> >> > fact i'm really curious. What is the next things on the roadmap ? Also
> >> > damien spoke in june to have a fixed release schedule (one every 6
> >> > months ?) is it still something in view ?
> >> >
> >> > - benoit
> >> >
> >>
> >>
> >>
> >> --
> >> Chris Anderson
> >> http://jchrisa.net
> >> http://couch.io
> >>
> >
>
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>
