You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Antony Blakey <an...@gmail.com> on 2008/11/28 23:37:39 UTC

Hierarchic Atachments/App Deployments (was: Hosting a Cappuccino application from CouchDB)

On 29/11/2008, at 7:39 AM, Justin Walgran wrote:

> That is incredibly helpful. Thank you.
>
> To take it a step further, I am very interested in Chris Anderson's
> work with distributing apps via CouchDB replication. Is there any way
> the LightsOut application could be incorporated as an attachment like
> Chris's Twitter application?

Hierarchic attachments would be really useful I think. I could  
certainly use them right now.

Because they don't exist, I'm building a notification handler that  
listens for documents with attributes that indicate that .zip  
attachments should be unpacked. I use a separate DB for such documents  
(to filter the notifications) and it will allow me to replicate  
existing static websites over Couch.

Delta replication of attachments would be useful (e.g. XDelta/RSync/ 
Unison) because then I could use either no-compression .zips,  
or .tars, and get much improved replication performance (I do this now  
in a different context).

I'm working on replicating both Smalltalk packages/files and Ruby gems/ 
files via Couch with a handler that manages the deployment and  
execution of such processes (driven by a definition document) for  
deploying applications (that use Couch) via Couch. It's particularly  
useful for Smalltalk because Smalltalk scalability is handled by  
running multiple instances on the same box (ST implementations  
generally use green threads with no native multithreading), which I  
can manage really easily using Erlang.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

You can't just ask customers what they want and then try to give that  
to them. By the time you get it built, they'll want something new.
   -- Steve Jobs




Re: Hierarchic Atachments/App Deployments (was: Hosting a Cappuccino application from CouchDB)

Posted by Justin Walgran <jw...@gmail.com>.
Damien,  I tried adding forward slashes to the file names to simulate
a hierarchy as you suggested, but this did not process the invoices
any further I filed the following bug report:

https://issues.apache.org/jira/browse/COUCHDB-167

-Justin

On Fri, Nov 28, 2008 at 6:10 PM, Damien Katz <da...@apache.org> wrote:
> I think should be possible to attach the files using directory slashes right
> in the filename. If that doesn't work, file a bug.
>
> -Damien
>
>
> On Nov 28, 2008, at 5:37 PM, Antony Blakey wrote:
>
>>
>> On 29/11/2008, at 7:39 AM, Justin Walgran wrote:
>>
>>> That is incredibly helpful. Thank you.
>>>
>>> To take it a step further, I am very interested in Chris Anderson's
>>> work with distributing apps via CouchDB replication. Is there any way
>>> the LightsOut application could be incorporated as an attachment like
>>> Chris's Twitter application?
>>
>> Hierarchic attachments would be really useful I think. I could certainly
>> use them right now.
>>
>> Because they don't exist, I'm building a notification handler that listens
>> for documents with attributes that indicate that .zip attachments should be
>> unpacked. I use a separate DB for such documents (to filter the
>> notifications) and it will allow me to replicate existing static websites
>> over Couch.
>>
>> Delta replication of attachments would be useful (e.g.
>> XDelta/RSync/Unison) because then I could use either no-compression .zips,
>> or .tars, and get much improved replication performance (I do this now in a
>> different context).
>>
>> I'm working on replicating both Smalltalk packages/files and Ruby
>> gems/files via Couch with a handler that manages the deployment and
>> execution of such processes (driven by a definition document) for deploying
>> applications (that use Couch) via Couch. It's particularly useful for
>> Smalltalk because Smalltalk scalability is handled by running multiple
>> instances on the same box (ST implementations generally use green threads
>> with no native multithreading), which I can manage really easily using
>> Erlang.
>>
>> Antony Blakey
>> --------------------------
>> CTO, Linkuistics Pty Ltd
>> Ph: 0438 840 787
>>
>> You can't just ask customers what they want and then try to give that to
>> them. By the time you get it built, they'll want something new.
>> -- Steve Jobs
>>
>>
>>
>
>
>

Re: Hierarchic Atachments/App Deployments (was: Hosting a Cappuccino application from CouchDB)

Posted by Damien Katz <da...@apache.org>.
I think should be possible to attach the files using directory slashes  
right in the filename. If that doesn't work, file a bug.

-Damien


On Nov 28, 2008, at 5:37 PM, Antony Blakey wrote:

>
> On 29/11/2008, at 7:39 AM, Justin Walgran wrote:
>
>> That is incredibly helpful. Thank you.
>>
>> To take it a step further, I am very interested in Chris Anderson's
>> work with distributing apps via CouchDB replication. Is there any way
>> the LightsOut application could be incorporated as an attachment like
>> Chris's Twitter application?
>
> Hierarchic attachments would be really useful I think. I could  
> certainly use them right now.
>
> Because they don't exist, I'm building a notification handler that  
> listens for documents with attributes that indicate that .zip  
> attachments should be unpacked. I use a separate DB for such  
> documents (to filter the notifications) and it will allow me to  
> replicate existing static websites over Couch.
>
> Delta replication of attachments would be useful (e.g. XDelta/RSync/ 
> Unison) because then I could use either no-compression .zips,  
> or .tars, and get much improved replication performance (I do this  
> now in a different context).
>
> I'm working on replicating both Smalltalk packages/files and Ruby  
> gems/files via Couch with a handler that manages the deployment and  
> execution of such processes (driven by a definition document) for  
> deploying applications (that use Couch) via Couch. It's particularly  
> useful for Smalltalk because Smalltalk scalability is handled by  
> running multiple instances on the same box (ST implementations  
> generally use green threads with no native multithreading), which I  
> can manage really easily using Erlang.
>
> Antony Blakey
> --------------------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> You can't just ask customers what they want and then try to give  
> that to them. By the time you get it built, they'll want something  
> new.
> -- Steve Jobs
>
>
>