Merge lp:~allenap/launchpad/lp-app-longpoll into lp:launchpad
Status: | Merged |
---|---|
Approved by: | Gavin Panella |
Approved revision: | no longer in the source branch. |
Merged at revision: | 13375 |
Proposed branch: | lp:~allenap/launchpad/lp-app-longpoll |
Merge into: | lp:launchpad |
Diff against target: |
702 lines (+617/-0) 12 files modified
lib/lp/app/configure.zcml (+1/-0) lib/lp/app/longpoll/__init__.py (+47/-0) lib/lp/app/longpoll/adapters/event.py (+47/-0) lib/lp/app/longpoll/adapters/subscriber.py (+56/-0) lib/lp/app/longpoll/adapters/tests/test_event.py (+84/-0) lib/lp/app/longpoll/adapters/tests/test_subscriber.py (+134/-0) lib/lp/app/longpoll/configure.zcml (+10/-0) lib/lp/app/longpoll/interfaces.py (+51/-0) lib/lp/app/longpoll/tests/__init__.py (+2/-0) lib/lp/app/longpoll/tests/test_longpoll.py (+104/-0) lib/lp/testing/fixture.py (+18/-0) lib/lp/testing/tests/test_fixture.py (+63/-0) |
To merge this branch: | bzr merge lp:~allenap/launchpad/lp-app-longpoll |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Graham Binns (community) | code | Approve | |
Review via email: mp+66872@code.launchpad.net |
Commit message
[r=gmb][no-qa] New lp.app.longpoll package.
Description of the change
New lp.app.longpoll package.
This provides a higher-level API on top of lp.services.
primary goal for now is to make it trivially easy to connect events in
the application to an interested page.
For example, an event in the application can be generated as simply
as:
emit(an_object, "event_name", {...})
and a page being prepared can arrange to receive these event via
long-poll with a single line of code:
subscribe(
Behind the scenes a new, short-lived, queue will be created and
subscribed to the correct routing key for the event. The in-page JSON
cache will have the queue details added to it so that the client can
immediately long-poll for events.
This branch contains the server-side code. The client-side code is
being worked on by Raphael.
To support the emit/subscribe two-step a single adapter must be
registered. It must (multi-) adapt the object that issues events and
an event description to an ILongPollEvent. This branch contains a
suitable base-class, LongPollEvent. Suppose a Job emits events from
_set_status using emit(self, "status", status.name) the following
adapter would work:
class JobLongPollEven
@property
def event_key(self):
return generate_event_key(
This ensures that there's a stable and consistent event naming scheme.
Hi Gavin,
Nice to see all the work from last week landing. This is a good branch; a few nits but nothing huge. r=me pending the changes below.
[1]
396 +class TestModule( TestCase) :
This seems like a bit of a generic name... Maybe TestSubscriberM odule for clarity?
[2]
446 + source = Attribute(
447 + "The event source.")
448 +
449 + event = Attribute(
450 + "An object indicating the type of event.")
Minor stylistic nit: I don't think these need to be spread over two lines.
[3]
556 +class TestModule( TestCase) :
Same as above. TestLongPollModule maybe?
[4]
560 + def test_subscribe( self):
576 + def test_emit(self):
681 + def test_register_ and_unregister( self):
DMMT. These could do with some leading comments explaining the expected behaviour so that I don't have to read the tests.