You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Johnny Weng Luu (JIRA)" <ji...@apache.org> on 2011/07/13 07:35:59 UTC
[jira] [Created] (COUCHDB-1219) Send data
Send data
---------
Key: COUCHDB-1219
URL: https://issues.apache.org/jira/browse/COUCHDB-1219
Project: CouchDB
Issue Type: New Feature
Reporter: Johnny Weng Luu
Priority: Minor
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push the data to other servers.
What I have to do right now to send the data to an external service is to setup a server (node.js) that listens on the _changes feed.
When there is a document meant for being delivered through email node.js will send a HTTP request to a email service (sendgrid).
I think it would make sense if CouchDB could make HTTP requests on document changes, so that we can eliminate that extra layer.
Why only HTTP server for data but not HTTP client for data.
(This would make even more sense if CouchDB was redesigned with node.js).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-1219) Send data
Posted by "Robert Newson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Newson closed COUCHDB-1219.
----------------------------------
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> I think this would make CouchDB even more suitable for couchapps.
> Now the app can be offline. We send an email and it will be sent by couchdb when Internet connectivity is there.
> Also now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1219) Send data
Posted by "Johnny Weng Luu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Johnny Weng Luu updated COUCHDB-1219:
-------------------------------------
Description:
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
Why only have a HTTP server for data but not a HTTP client for data.
I think this would make CouchDB even more suitable for couchapps.
Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
was:
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
Why only have a HTTP server for data but not a HTTP client for data.
I think this would make CouchDB even more suitable for couchapps.
Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
(This would make even more sense if CouchDB was redesigned with node.js).
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> I think this would make CouchDB even more suitable for couchapps.
> Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1219) Send data
Posted by "Johnny Weng Luu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Johnny Weng Luu updated COUCHDB-1219:
-------------------------------------
Description:
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
Why only have a HTTP server for data but not a HTTP client for data.
I think this would make CouchDB even more suitable for couchapps.
Now the app can be offline. We send an email and it will be sent by couchdb when Internet connectivity is there.
Also now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
was:
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
Why only have a HTTP server for data but not a HTTP client for data.
I think this would make CouchDB even more suitable for couchapps.
Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> I think this would make CouchDB even more suitable for couchapps.
> Now the app can be offline. We send an email and it will be sent by couchdb when Internet connectivity is there.
> Also now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1219) Send data
Posted by "Johnny Weng Luu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Johnny Weng Luu updated COUCHDB-1219:
-------------------------------------
Description:
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
Why only have a HTTP server for data but not a HTTP client for data.
I think this would make CouchDB even more suitable for couchapps.
Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
(This would make even more sense if CouchDB was redesigned with node.js).
was:
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
Why only have a HTTP server for data but not a HTTP client for data.
I think this would make CouchDB even more suitable for couchapps.
(This would make even more sense if CouchDB was redesigned with node.js).
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> I think this would make CouchDB even more suitable for couchapps.
> Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
> (This would make even more sense if CouchDB was redesigned with node.js).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1219) Send data
Posted by "Randall Leeds (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066202#comment-13066202 ]
Randall Leeds commented on COUCHDB-1219:
----------------------------------------
There's a lot more to this than just making an HTTP client, and it doesn't require using Node.
couchjs implements the JavaScript view server on an embedded SpiderMonkey. It's written in C. It has optional bindings to libcurl and a simple HTTP client is already made because it's used for running the javascript tests from the command line. That client is not exposed in any of the javascript functions CouchDB runs, but specifically exposed by the test harness. It's easy enough to inject into the global namespace of any other JavaScript we run.
However, the complexity is more at a Couch API level and not at the level of creating this HTTP client. For example, we would *not* want to expose the HTTP client to a map or reduce function because that's removing the isolation that encourages determinism in views. We could, possibly, expose it to a _list, or a _show is a object in the global namespace. We'd probably want to allow it to be globally disabled, so hosted services like IrisCouch don't have to worry about their servers being abused.
So, exposing a basic HTTP client is easy. Exposing a *good* one that a hosted CouchDB provider can trust to obey CORS, not hog server resources, etc, is probably more tricky. Finding a place to expose it is the hardest part for me and always sends me into a spiral of designing the 2.0 view server. I'm not going to bikeshed that here, though I'm open to talking about it on the lists.
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> I think this would make CouchDB even more suitable for couchapps.
> Now the app can be offline. We send an email and it will be sent by couchdb when Internet connectivity is there.
> Also now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1219) Send data
Posted by "Johnny Weng Luu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Johnny Weng Luu updated COUCHDB-1219:
-------------------------------------
Description:
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
Why only have a HTTP server for data but not a HTTP client for data.
(This would make even more sense if CouchDB was redesigned with node.js).
was:
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push the data to other servers.
What I have to do right now to send the data to an external service is to setup a server (node.js) that listens on the _changes feed.
When there is a document meant for being delivered through email node.js will send a HTTP request to a email service (sendgrid).
I think it would make sense if CouchDB could make HTTP requests on document changes, so that we can eliminate that extra layer.
Why only HTTP server for data but not HTTP client for data.
(This would make even more sense if CouchDB was redesigned with node.js).
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> (This would make even more sense if CouchDB was redesigned with node.js).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1219) Send data
Posted by "Robert Newson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Newson resolved COUCHDB-1219.
------------------------------------
Resolution: Not A Problem
It's an interesting idea but the 'new feature' mechanism, in my opinion, is for active developers to track and publicize their progress, it's not a suggestion box (use the user@ mailing list for that).
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> I think this would make CouchDB even more suitable for couchapps.
> Now the app can be offline. We send an email and it will be sent by couchdb when Internet connectivity is there.
> Also now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1219) Send data
Posted by "Robert Newson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064586#comment-13064586 ]
Robert Newson commented on COUCHDB-1219:
----------------------------------------
Sounds interesting, how far have you got?
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> I think this would make CouchDB even more suitable for couchapps.
> Now the app can be offline. We send an email and it will be sent by couchdb when Internet connectivity is there.
> Also now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1219) Send data
Posted by "Johnny Weng Luu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065031#comment-13065031 ]
Johnny Weng Luu commented on COUCHDB-1219:
------------------------------------------
You mean implementing this feature?
Have to disappoint .. don't know Erlang so I can't contribute with features.
However, I thought if you could send data with CouchDB, Couchapps would be more powerful.
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> I think this would make CouchDB even more suitable for couchapps.
> Now the app can be offline. We send an email and it will be sent by couchdb when Internet connectivity is there.
> Also now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1219) Send data
Posted by "Johnny Weng Luu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065131#comment-13065131 ]
Johnny Weng Luu commented on COUCHDB-1219:
------------------------------------------
Can't I use the "Wish" type? I don't find a mailing list good for feature suggestions. They just get lost.
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> I think this would make CouchDB even more suitable for couchapps.
> Now the app can be offline. We send an email and it will be sent by couchdb when Internet connectivity is there.
> Also now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1219) Send data
Posted by "Johnny Weng Luu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Johnny Weng Luu updated COUCHDB-1219:
-------------------------------------
Description:
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
Why only have a HTTP server for data but not a HTTP client for data.
I think this would make CouchDB even more suitable for couchapps.
(This would make even more sense if CouchDB was redesigned with node.js).
was:
With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
Why only have a HTTP server for data but not a HTTP client for data.
(This would make even more sense if CouchDB was redesigned with node.js).
> Send data
> ---------
>
> Key: COUCHDB-1219
> URL: https://issues.apache.org/jira/browse/COUCHDB-1219
> Project: CouchDB
> Issue Type: New Feature
> Reporter: Johnny Weng Luu
> Priority: Minor
>
> With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc.
> It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers.
> What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed.
> When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service.
> I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data.
> Why only have a HTTP server for data but not a HTTP client for data.
> I think this would make CouchDB even more suitable for couchapps.
> (This would make even more sense if CouchDB was redesigned with node.js).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira