Getting Started on Lattice

[Ryan Cook]

I'm interested in being a part of the effort to start building Lattice: https://github.com/celluloid/lattice . Tony has outlined at a high-level what the framework might provide in the README and hinted at some other important things in older threads on this list.

After a brief email conversation, it was suggested that a true/real design document be created to guide the development of the framework. At the risk of sounding silly, I have no idea what that means. Moving the discussion here, can anyone point to a good example design document or outline for one? Would this be something that could be maintained in the repo wiki?

Ryan

[Josh Adams]

I'm completely interested in this as well.  I'm a huge fan of Readme Driven Design documents as a starting point, maybe we can just start something like that going?  Typically you'll just start out a README that defines how to use the thing you want to build, then write tests that would pass if it existed, then make the tests green and drink cocoa.  Amirite?

--
Josh Adams
CTO | isotope|eleven
[cell] (205) 215-3957
[work] (877) 476-8671 x201

[Tony Arcieri]

On Thu, Nov 8, 2012 at 9:08 AM, Ryan Cook <coo...@gmail.com> wrote:

After a brief email conversation, it was suggested that a true/real design document be created to guide the development of the framework. At the risk of sounding silly, I have no idea what that means. Moving the discussion here, can anyone point to a good example design document or outline for one? Would this be something that could be maintained in the repo wiki?

Yeah, this can definitely go in the Wiki. What I was thinking of for starters is at least a high level outline of what the components of the system are and where they're coming from.

The beginnings of this are in the README but it needs to be expanded.

--
Tony Arcieri

[Ryan Cook]

Right on! I'm all about the cocoa.

Tony: the wiki has not yet been generated yet on the repo. I think all you have to do is visit the page. Can you let us know after you have a minute to click through?

https://github.com/celluloid/lattice/wiki

Thanks!

Ryan

--
Ryan Cook
720.319.7660

[Tony Arcieri]

Boom

--
Tony Arcieri

[Ryan Cook]

Started here: https://github.com/celluloid/lattice/wiki/Design-Document-Index

Thoughts?

--
Ryan Cook
720.319.7660

[Alexander Flatter]

Hello,

It's good to see some movement around Lattice. Being based on Celluloid, it has the chance to really be a new kind of framework in the Ruby world.

Cells: Lattice's go-to domain model object. Cells represent data dependencies of resources, or are resources themselves. Every Cell is a Celluloid actor (…)

I'm not sure what is meant by "resource" here. In case we're talking about webmachine resources: webmachine by default creates resource instances for each request [1]. This stands in contrast to "every cell is an actor", but can potentially be changed.

I love the idea of explicit data dependencies. A cell could register with its dependencies and be notified when data changes. This can be used for automatic cache invalidation. Or going further, the notifications could be forwarded to the browser via websockets - an awesome feature in the world of fat client-side applications.

[1] https://github.com/seancribbs/webmachine-ruby/blob/master/lib/webmachine/dispatcher.rb#L73

[Tony Arcieri]

I'm not sure what is meant by "resource" here. In case we're talking about webmachine resources: webmachine by default creates resource instances for each request [1]. This stands in contrast to "every cell is an actor", but can potentially be changed.

Yes, the idea of "resource" is that it's a Webmachine resource. There's no conflict here: actors can be ephemeral and die at the end of a request. On JRuby 1.7, I'm able to create 10,000 actors a second so I don't anticipate a performance bottleneck here, at least for Rails-like single application instance loads. Celluloid pools threads so ephemeral actors shouldn't be a problem.

Resources are the glue between the incoming requests and the other cells in the system. Perhaps other cells can persist between requests (with an optional inactivity timeout?) but I think the resource cells should follow a Webmachine-like lifecycle and only exist for the duration of the request.

The main use case is scatter/gather programming: you want a request for a resource to kick off many other cells hitting backend services in parallel and assembling the result. Celluloid Futures can provide the glue for gathering the results.

--
Tony Arcieri