abstractive / ecell Goto Github PK

In many cases, it's less than ideal to use ØMQ's synchronous sockets, but the communication being done is still in one-reply-to-one-request form. ECell's logic for handling these cases is spread out a bit through the code (mostly in Calling, Management, and line_handlers.rb), and is the source of some failures to be DRY.

I think it'd be a good idea to write a new class (or maybe just add methods to Line) that abstract over this use case. Interface-wise, it'd provide a method which you call with the message to send that then synchronously returns the response, so that rep = line << req; rep = rep.wait can be replaced with rep = something.the_method(req).

If done correctly, I think this rid of the need for the hardcoding in Constants::RETURNS.

Complete GitHub Wiki or GitBook:

• definitions of Terms used
• API basics & example usage
• means of extending/expanding.

Code to place in examples/multiple/*.rb demonstrating a 3+ machine mesh, with 5+ pieces.

• The name is a relic.
• Most of its functionality is unused or fairly trivial.
• It does global state stuff.

Piece which behaves as Reel http/s|ws/s server, solely:

• Provides access to static files on the host in a specific directory ( and its contained directories, recursively )
• Outputs request statistics to logger ( summary of every request: url, time to serve, method, host address )

Right now, Designs list which Lines a Figure should initialize when it's started. It might be a good idea to replace that with plain calls to initialize_line in a startup hook.

Not sure whether this is a good idea, but I think it's worth considering. It reduces complexity.

Right now it's just commented out. Is that because it's broken and I should fix it while migrating, or because it's abandoned and should be left out?

If follower_attach is called with a piece that the leader thinks it's already attached to, it will refuse to try attaching again unless it can't ping the piece. At the same time, pieces that are noted as unresponsive aren't actually deleted from the list of attached pieces. Together, this means that when a service goes down and comes back up, its leader will think it's still attached, so it will refuse to attach again.

Carrying on from #3, take the Admin design to its logical conclusion, providing specialized "system administration" functionality:

• Detect crash of Subject
• Re-spawn crashed Subject
• Handle initial launch of each Piece required to have all Subject instances present to comprise a fully capable mesh.
• Become capable of being the single-point of administration for an entire mesh, or mesh-partition; similarly to how Monitor is the single-point of observation for an entire mesh, or mesh-partition.

Should I put a license in the repo? If so, do you already have one in mind, or would LGPL 3 be OK?

Replace Stroke autoloading with something that works basically like Shape loading - you provide both a Line ID to supervise as, and a Stroke to instantiate.

Apart from reducing magic, this gets rid of the awkward necessity of having a bunch of identical Strokes with different names, and gets rid of the constraints on Line IDs.

Should I split Coordinator into Distribute and Collect, or should I keep those two pieces of functionality in one Face? Operative has already been renamed to Process; if I did the split, Distribute would be the Face for pushing out tasks, and Collect would be the face for collecting processed results.

I'm asking primarily about the split, not about the specific names for the split pieces.

Basic foundation for test-suite, focusing to start-with on base objects.

(checklist by benzrf)

• Enumerate stuff to test.
• Enumerate testable behavior in each thing.
• Write tests.

Code to place in examples/single/*.rb demonstrating a 1 machine mesh, with 5+ pieces.

What should I do about the copyright notices?

They're in the following files:

• lib/ecell/base/sketches/webstack/puma.rb
• lib/ecell/base/sketches/webstack/web_server.rb

Create a webstack-reel Sketch alongside what we have now, which would become webstack-puma or webstack-rack or webstack-sinatra or similar.

Designs should really be composable somehow.

I'd like to eventually rework Designs to be declared using a method-based DSL instead of directly as data structures - this will make it both easier to document the options available in them, and make mistakes in their definitions result in errors instead of silently passing.

I'm sorry I was unable to wait for explicit approval before posting the code @rjattrill, but I did not want to penalize @benzrf for my time constraints. The two areas I am drawing attention to are these:

• https://github.com/celluloid/ecell/tree/master/lib/ecell/base/sketches/webstack
• https://github.com/celluloid/ecell/tree/master/lib/ecell/base/sketches/process

But most of all this one file:

• https://github.com/celluloid/ecell/blob/master/public/WebSocketClient.swf

In fact on that last one, if not only we can have your clearance here in writing but also have the source code to that tester, that would be even better.

Please also note the citation format used:

https://github.com/celluloid/ecell#originators

And also the current License in effect:

https://github.com/celluloid/ecell/blob/master/LICENSE.md

Is this something thats being developed?