g ddocs could very
> >> well have larger ramifications for the source code base; this
> >> decision should not be made lightly and definitely should not be
> >> made on marketing@.
> >>
> >> -Joan
> >>
> >> - Original Message -
&
keting@.
>>
>> -Joan
>>
>> - Original Message -----
>>> From: "Jan Lehnardt"
>>> To: marketing@couchdb.apache.org
>>> Sent: Wednesday, May 6, 2015 9:28:54 AM
>>> Subject: Re: How do CouchApps fit into the CouchDB story?
I'm going to step in and describe my story of learning about
CouchDB for the first time, how CouchApps played into that, and how
after thinking they were the bees' knees, I've come to hate them.
I first learned of CouchDB while in grad school doing textual
analysis of synchronously medicated stude
> On 06 May 2015, at 21:38, Miles Fidelman wrote:
>
> Jan Lehnardt wrote:
>>
>>> Re. a couple of things below:
> This should be definitely something @users should be involved in.. at
> least
> those interested in Couchapps.
>
> To recap:
> Jan: wants to remove Couchapp
Jan Lehnardt wrote:
Re. a couple of things below:
This should be definitely something @users should be involved in.. at least
those interested in Couchapps.
To recap:
Jan: wants to remove Couchapp name and design doc functions because it
finds them to be source of confusion
This does not ade
t;>>>>>> As I had been around and participated when JChris,
>>>>>>>>> Jan and others
>>>>>> started
>>>>>>>>> CouchApps and Benoit took over the work, I am a bit
>>>>>>>>> sad, that
>
> Sure, but how is that conceptually different?
Well... Imagine doc with 100 attaches in CouchDB and then 101 object in
Riak.
Now, compare them in these situations:
1. What happens when replication breaks in the middle?
1. How we can determine it happened?
2. What can we do with h
> On 06 May 2015, at 19:47, ermouth wrote:
>
>>> Imho replication with attachments – typed blobs – is main feature.
>> This makes no sense. Riak has that too.
>
> No, it does not.
>
> 1) Typed blobs in Riak are just objects, not attachments to objects
Sure, but how is that conceptually differ
>> Imho replication with attachments – typed blobs – is main feature.
> This makes no sense. Riak has that too.
No, it does not.
1) Typed blobs in Riak are just objects, not attachments to objects
2) They have limits – blobs larger than 50Mb are not recommended (in real
life I‘d say reasonable li
> On 06 May 2015, at 19:03, ermouth wrote:
>
>>> CouchDB’s core feature is geographically distributed replication.
>
>> Really? That's the argument that lead to CouchBase.
>
> I think Jan just forgot to say ‘with attachments’. Attachments are really
> important, if CouchDB had no attachments,
> On 06 May 2015, at 18:54, Miles Fidelman wrote:
>
> Jan Lehnardt wrote:
>>> On 06 May 2015, at 17:57, Giovanni Lenzi wrote:
>>>
>>> Given the importance of the topic: the future of couchapp... I'm moving
>>> this from the @marketing to the user@ mailing list.
>> I’d say this is too early, wou
>> CouchDB’s core feature is geographically distributed replication.
> Really? That's the argument that lead to CouchBase.
I think Jan just forgot to say ‘with attachments’. Attachments are really
important, if CouchDB had no attachments, I‘d better use couchbase.
Imho replication with attachme
Jan Lehnardt wrote:
On 06 May 2015, at 17:57, Giovanni Lenzi wrote:
Given the importance of the topic: the future of couchapp... I'm moving
this from the @marketing to the user@ mailing list.
I’d say this is too early, would prefer we keep this on marketing@ until
we have the messaging right.
;>>>>
>>>>>>>>> On 05 May 2015, at 11:49, Jan Lehnardt wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05 May 2015, at 11:08, Andy Wenk wrote:
>>>>
;
>>>>>>>>> We should give CouchApps a place to live in the CouchDB ecosystem
>>>> (not
>>>>>>>>> meant technically). So my proposal is to reactivate couchapp.org
>>> and
>>>>>> write
&
uld not be made lightly and definitely should not be
> made on marketing@.
>
> -Joan
>
> - Original Message -
>> From: "Jan Lehnardt"
>> To: marketing@couchdb.apache.org
>> Sent: Wednesday, May 6, 2015 9:28:54 AM
>> Subject: Re: How do
made lightly and definitely should not be
made on marketing@.
-Joan
- Original Message -
> From: "Jan Lehnardt"
> To: marketing@couchdb.apache.org
> Sent: Wednesday, May 6, 2015 9:28:54 AM
> Subject: Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB
Heya,
great discussion here, let’s keep it going!
I love the idea of getting a few more people into a joint session to discuss
the future of CouchApps, as Johs suggested.
The current thread is focussing on “how to fix CouchApps”, which we should
continue to figure out.
I’d also like push towa
On Wed, May 6, 2015 at 3:15 PM, Johs Ensby wrote:
>> On 06 May 2015, at 13:55, Giovanni Lenzi wrote:
>>
>> They could also be:
>> - design doc app
>> - design app
>> - couchdb apps
>> - couchdb based apps
>>
>> But they all seem very complicated to me. What do you think?
>
> I would prefer to thi
> On 06 May 2015, at 13:55, Giovanni Lenzi wrote:
>
> They could also be:
> - design doc app
> - design app
> - couchdb apps
> - couchdb based apps
>
> But they all seem very complicated to me. What do you think?
I would prefer to think of the “app” as a combination of things that use ddoc
to
;>>>
> > >>>>>>>>
> > >>>>>>>> On 05 May 2015, at 11:08, Andy Wenk
> wrote:
> > >>>>>>>>
> > >>>>>>>> Hi,
> > >>>>>>>>
> > &
> On 06 May 2015, at 07:49, Johs Ensby wrote:
>
> Jan and Giovanni,
> I am afraid I am dumbing down the discussion here (Giovanni, sorry for not
> studying your docs in detail yet), but isn’t this very basic?
> a vhost point all requests directly to the _rewrite that is used to manage
> securi
>> meant technically). So my proposal is to reactivate couchapp.org
> >> and
> >>>>> write
> >>>>>>>> one page with info about
> >>>>>>>>
> >>>>>>>> * what CouchApps are
> >>&g
meant technically). So my proposal is to reactivate couchapp.org
> >> and
> >>>>> write
> >>>>>>>> one page with info about
> >>>>>>>>
> >>>>>>>> * what CouchApps are
> >>>>>
@ermouth
> http://cloudwall.me/etc/json-editor.html – gonna make it couchapp editor,
AWESOME... cloudwall already deals with documents and attachments, so you
are already probably not too-far ahead.. That would be awesome!! That
could really dramatically increase adoption-rate, by making CouchDB t
Jan and Giovanni,
I am afraid I am dumbing down the discussion here (Giovanni, sorry for not
studying your docs in detail yet), but isn’t this very basic?
a vhost point all requests directly to the _rewrite that is used to manage
security
the _rewrite decides what to forward to the databases (wit
>>> was
>>>>>>>> foolish Jan ;-)). It is our responsibility to clarify what
>> CouchApps
>>>>> are
>>>>>>>> and why one should move forward to sth. better. With clarification
>>
t;>>> All the best
> > >>>>>
> > >>>>> Andy
> > >>>>>
> > >>>>>
> > >>>>> On 5 May 2015 at 10:54, Jan Lehnardt wrote:
> > >>>>>
> > >>>>>>
t;>>>
> >>>>>> Con:
> >>>>>> - the concept of compiling design docs is confusing
> >>>>>> - even when they get it, they are confused that they need a third
> >> party
> >>>>>> tool called `couchapp` to do so
> On 05 May 2015, at 18:53, Giovanni Lenzi wrote:
>
>> I found a massive security concern
>
> I still haven't heard of a single path for exploit, but ok...
I make a GET request to
http://:/database/_all_docs?include_docs=true authenticated
as one of your users, with your couchapp in it. In C
> I found a massive security concern
I still haven't heard of a single path for exploit, but ok... everyone will
remain with his own convinctions
Thanks for your patience too
2015-05-05 17:09 GMT+02:00 Jan Lehnardt :
>
> > On 05 May 2015, at 16:36, Giovanni Lenzi wrote:
> >
> >> otherwise, ag
tion.
>>>>>>
>>>>>> Let’s think about how (and if) we can fit the CouchApp story into a
>>>>>> coherent CouchDB story.
>>>>>>
>>>>>> A prerequisite for that is having a coherent CouchDB story, which we
&g
gt;>> position, this isn’t meant as a basis for discussion)
> >>>>
> >>>> I’m personally conflicted. When we set out to develop CouchApps, we
> >>>> thought we are inventing a new paradigm for how to build the web, and
> >>>> e
wer and
>>>> attention.
>>>>
>>>> That all led me to re-evaluate the whole value proposition, when things
>>>> like PouchDB came up and the browser became a decent application
>>>> development platform. That whole thinking led to the crea
> On 05 May 2015, at 16:36, Giovanni Lenzi wrote:
>
>> otherwise, again, the system is insecure (I helped build it that way).
> To tell the truth, with handlers renaming or as soon as an attacker doesn't
> know your db name, the system can still be secured withouth any proxy.
> However,
> if pr
mbraces browser-to-server sync to allow fully offline apps, it allows
>>> all-javascript-all-json development on the front- and back-end. It uses the
>>> database-per-user and the _changes-feed-as-async-worker paradigms and it is
>>> all wrapped into a package that is *r
> otherwise, again, the system is insecure (I helped build it that way).
To tell the truth, with handlers renaming or as soon as an attacker doesn't
know your db name, the system can still be secured withouth any proxy. However,
if proxy is really a concern, a fix to use CouchDB only, could eventua
On Tue, May 5, 2015 at 4:48 PM, ermouth wrote:
> 2. Log does not rotate (very serious vulnerability)
That's a work for logrotate, so which we actually ship rules set
https://github.com/apache/couchdb/blob/1.6.1/etc/logrotate.d/couchdb.tpl.in
--
,,,^..^,,,
> On 05 May 2015, at 15:50, Giovanni Lenzi wrote:
>
>> CouchDB has no way of blocking requests to _changes that have no filter
> parameter
> Why? _rewrite handler is used to allow only requests complying with your
> api, and therefore preventing requests to changes withouth a filter. You
> can h
> CouchDB has no way of blocking requests to _changes that have no filter
parameter
Why? _rewrite handler is used to allow only requests complying with your
api, and therefore preventing requests to changes withouth a filter. You
can have a look to rewrites.json file for this.
I agree proxy is a b
> All dummy requests can be blocked before getRow call
No. Map function call costs. Serialization costs. Deserialization costs.
Parsing request costs.
Giovanni, let me tell you my story in short – you are so passionate in
advocating couchapps as I was 4 years ago )
When I discovered CouchDB, I
> On 05 May 2015, at 15:14, Giovanni Lenzi wrote:
>
>> That happens in a proxy outside of CouchDB then?
>
> No, it happens in the changes filter of the design document.
You cannot force a client to use a filter. CouchDB has no way of blocking
requests to _changes that have no filter parameter
The full couchapp is also on github:
https://github.com/Smileupps/couchapp-chatty
2015-05-05 15:14 GMT+02:00 Giovanni Lenzi :
> > That happens in a proxy outside of CouchDB then?
>
> No, it happens in the changes filter of the design document.
>
>
>
> That happens in a proxy outside of CouchDB then?
No, it happens in the changes filter of the design document.
>>>>>>>>
>>>>>>>> Let’s think about how (and if) we can fit the CouchApp story into a
>>>>>>>> coherent CouchDB story.
>>>>>>>>
>>>>>>>> A prerequisite for that is having a
> _list function checks if query has user as a first-level key
Exactly!
> expensive when you have hundreds
There are many rooms for improvements with ACL at view level
> we check ACL after fetching data, not before.
isn't data fetched by getRow function? All dummy requests can be blocked
before g
t” narrative that
> >>>> emphasises
> >>>>>> replication between CouchDB instances and other projects that speak
> >> the
> >>>>>> replication protocol (especially PouchDB and TouchDB).
> >>>>>>
> >>>>
;
>>>>>>
>>>>>> * * *
>>>>>>
>>>>>> (Personal view alert: this is just to give some more background on my
>>>> own
>>>>>> position, this isn’t meant as
> How do you do per-doc or per-attachment ACL? Those are not core CouchDB
features.
_list function checks if query has user as a first-level key and it matches
caller. Then list resend map result if user have permissions. So most of
the time CPU serialize, then deserialize, then again serialize ma
able a true p2p web.
> >> That
> >>>> didn’t happen and probably was a little foolish of us :D
> >>>>
> >>>> Technically, that would have meant CouchApps had to grow a lot more
> and
> >>
on.
>>>>
>>>> That all led me to re-evaluate the whole value proposition, when things
>>>> like PouchDB came up and the browser became a decent application
>>>> development platform. That whole thinking led to the creation of Hoodie
>> (
>>&g
> wanted to address the limitations that would stifle their adoption.
> Hoodie
> >> embraces browser-to-server sync to allow fully offline apps, it allows
> >> all-javascript-all-json development on the front- and back-end. It uses
> the
> >> database-per-user an
> How can we make it that CouchApps strengthen CouchDB and not weaken it by
adding confusion?
1) Just telling true about couchapps.
2) Creating modern robust tooling.
3) Improving ‘map >> serialize >> deserialize >> list’ sequence. It‘s
ineffective.
For #1.
Definitely, there exist archiectures,
nc-worker paradigms and it is
>> all wrapped into a package that is *really* easy to understand and get
>> started with. Hoodie, unlike CouchApps, does have a fighting chance of
>> making CouchDB’s unique features (replication, _changes) available for a
>> larger population and
excited about that.
>
> * * *
>
> All that doesn’t mean, however, that CouchApps don’t have their place, but
> again, I’m not sure where that place is and the place it currently has
> seems to negatively affect CouchDB, so I’d like for this list to think and
> talk a
CouchDB and not weaken it by
adding confusion?
How do CouchApps fit into the CouchDB story?
Best
Jan
--
> On 05 May 2015, at 08:45, ermouth wrote:
>
>> CouchDB-killing answers
>
> Well... When someone says couchapps is silver bullet – I say ‘No’ and I can
> prove it. Co
56 matches
Mail list logo
