search

ejpbruel / factor

Mozilla Public License 2.0
1 stars 0 forks source link

We need a way to integrate Factor with the devtools server. #1

Open ejpbruel opened 8 years ago

ejpbruel commented 8 years ago

Now that we've demonstrated Factor as a proof of concept, we need to come up with a viable migration path. Ideally, people should be able to use Factor on an opt-in basis, without any changes to their existing actors. Jryans suggested he may have some ideas to accomplish this.

If using Factor on an opt-in basis turns out to be impossible for some reason, the next best thing would be to reimplement the protocol.js API on top of Factor, so that most of the existing devtools actors can be used with no to minimal change.

An additional requirement is that we should not pollute the Factor repository with concepts from the devtools server: Factor is intended to be a standalone library. It should either be hooked into the existing devtools server, or the devtools server should be layered on top of it.

I'm opening this issue to serve as a central point to discuss implementation strategies to achieve the above goals.

jryans commented 8 years ago

After talking on Vidyo for a bit, Eddy and I felt the first step with the least migration risk would be to allow a particular actor using Factor to hook into the server to receive RDP messages. So for some existing actor you wish to use Factor with, protocol.js is still used for client <-> server messaging, but Factor takes over on the server. This would involve the least conversion, since you only apply Factor (for now) on the server side when actor <-> actor coordination, etc. is needed.

Directing an incoming packet to Factor (instead of protocol.js) is easy to do with no or minimal change to the server, since it already looks up the destination in an actor pool. Factor could either register in the pool, or add a similar routing path to take over.

One challenge is that this would bypass the protocol.js server packet handling path, even though we're still describing the client <-> server set of actions using protocol.js. @ejpbruel, would you "redescribe" all the possible actor messages in the Factor implementation then? Or would your wrapper examine the messages that were described in the protocol.js actor? It could be unfortunate if we have to maintain two sets of the possible messages for two frameworks