Menu
▾
▴
mod-pubsub-developer — Developer list for mod_pubsub
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(45) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(16) |
Feb
(23) |
Mar
(62) |
Apr
(33) |
May
(35) |
Jun
(37) |
Jul
(45) |
Aug
(15) |
Sep
(22) |
Oct
(41) |
Nov
(23) |
Dec
(17) |
| 2004 |
Jan
(14) |
Feb
|
Mar
(55) |
Apr
(8) |
May
(1) |
Jun
(11) |
Jul
|
Aug
|
Sep
(20) |
Oct
(11) |
Nov
(10) |
Dec
(14) |
| 2005 |
Jan
(4) |
Feb
(2) |
Mar
(6) |
Apr
(26) |
May
(5) |
Jun
(11) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(18) |
Dec
(40) |
| 2007 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Alex R. <al...@ne...> - 2004-03-26 23:24:40
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 26 March 2004 2:05 pm, George Schlossnagle wrote: > Hi, > > Joyce Park has been talking to me about porting mod_pubsub to use > the twisted event framework. I've done some poking around and > wanted to share some assessments before I start work in earnest: > > In your main event loop, you currently do this: > > while server.alive: > asyncore.poll(scheduler.timeout()) > scheduler.run() Right. This was the primary discussion point around=20 poll/select/kqueue/epoll. We all realize that this is horrendously=20 inefficient. The Plan (TM), as I understand it, is to move this to a=20 Twisted reactor and then use the appropriate reactor for the system=20 at hand (kqueue, epoll, etc...). Someone had mentioned libevent on Wed, and I'm considering writing a=20 reactor for it, which would ease the portability issues further. [ snip ] > Actual implementation aside, is their any reason I'm missing as to > why this is a bad idea?=20 Nope, it's exactly the right approach. Regards =2D --=20 Alex Russell al...@bu... BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7 al...@ne... F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAZLiuoV0dQ6uSmkYRAunUAKDI9jskaFwpZCmvIAp/xaFhN+OP0gCgsOS+ /z3jZEZfppqRU3PpIdsCufc=3D =3DfAKv =2D----END PGP SIGNATURE----- |
|
From: George S. <ge...@om...> - 2004-03-26 22:03:50
|
Hi,
Joyce Park has been talking to me about porting mod_pubsub to use the
twisted event framework. I've done some poking around and wanted to
share some assessments before I start work in earnest:
In your main event loop, you currently do this:
while server.alive:
asyncore.poll(scheduler.timeout())
scheduler.run()
which basically polls with a timeout equal to the minimum time of any
scheduled event, handles those, and then does a linear search through
the entire list of scheduled events looking for ones which are
runnable. Having to do a linear search though the scheduled event list
is relatively slow, prone to race conditions, and I can't think of a
good reason that it shouldn't be handled internal to the event system.
In moving to twisted, I would like to pull the scheduled events into
the twisted system itself, using the twisted reactors native support
for time-scheduled events.
Actual implementation aside, is their any reason I'm missing as to why
this is a bad idea? I have a partial port running that incorporates
this functionality with twisted and it works well.
George
|
|
From: Alex R. <al...@ne...> - 2004-03-26 19:53:29
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 26 March 2004 10:44 am, Joyce Park wrote: > Hey guys, > > So we had a fabulous meeting Wednesday night, mostly focused on > server improvements. My notes are appended. Old Mod-pubsubbers > also had a chance to meet the fresh blood, Alex and Vishy and > Henry, who are pushing the effort on behalf of Friendster. It was really neat to meet everyone. I (for one) and very excited=20 about the possiblity of getting modpubsub to be scalable enough to=20 handle some of the loads we are discussing. [snip] > Performance > --memory > --long queues (delivery bug) > --select() So to outline this problem a little bit more for the list, the=20 traditional select() and poll() mechanisms available on POSIX systems=20 require a main-loop iteration over a list of open file descriptors to=20 determine if an action needs to happen for a given file descirptor.=20 When that list becomes very long, that traversal becomes increasingly=20 expensive, chewing up lots of CPU time that we (as app programmers)=20 would like to be using to actually _do_ something. Given that clients of modpubsub protocol servers generally require=20 long-lived connections in order to acheive low-latency, modpubsub=20 essentially forces worst-case behavior of select() and poll().=20 =46ortunantly, OS manufacturers have recently come to our rescue with=20 kqueue/kevent (FreeBSD and OS X) and epoll (Linux 2.6). These=20 event-driven file descriptor change notification syscalls allow app=20 programmers to register callbacks which are called when something=20 happens, so apps can spend less time figuring out if they need to do=20 something, and more time actually _doing_ things. This asynchronous=20 approach is how we intend to get modpubsub servers supporting 10K=20 concurrent clients. This also dove-tails into using the Twisted async=20 framework for the Python server nicely. > --old event initial route population has a long pause > --HTTP 1.1 HTTP 1.1 will buy us chunking and reusable connections. These are both=20 Good Things (TM). > --robust (lazy expiration) > --topics never die > --overhead for reaping > > Security > --SSL It was noted that in REALLY BIG installations, SSL is still expensive,=20 but might allow moderately sized sites/apps to allow HTTP 1.1 through=20 proxies. > --authentication > --security Security requirements seem to be one of the largest areas for=20 improvement. It was decided that authentication and authorization=20 shouldn't be handled in the server deamon itself, but rather that the=20 server should expose sane "hooks" or proxy-points to allow an=20 external security monitor service to give the thumbs up or down to a=20 message. The discussion about Unix Domain Sockets sprung out of this=20 approach to security, sinc we'll need REALLY fast IPC to get this=20 working well. > --do_method=3Dbatch loses errors, error handling unspecified > --sequencing (events have to be delivered in order) > --auth/auth policy callbacks or hooks > --e.g. unix-domain-sockets This point refers to a concept of talking the modpubsub HTTP protocol=20 over a UDS and that a security monitor could then insert itself into=20 the processing stream via this connection. > --disable introspection > > Latency > > Scalability > --10K connections/box With fewer connections than this supported by a single server, the=20 communications overhead for replication and failover looks to become=20 overwhelming. > Failover > --topic-based expiration policy Since topics are events, events can expire their sub-events, and=20 therefore topics can enforce sub-topic expiration. This seemed an=20 elegant way of dealing with te reaping problem, but we don't have any=20 experience with this in the wild. Time will tell if this design=20 works. > --weak ref topic for route dest > --lease-extension for expiring objects Topic creation events for existing topics will re-set their=20 time-to-expire timestamps and then be dropped. This seems a good way=20 to allow applications to do topic "keepalive". I'm sure others will have better clarifications. Regards =2D --=20 Alex Russell al...@bu... BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7 al...@ne... F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAZIrGoV0dQ6uSmkYRApRkAJ9+1Ls9Ztq7I18VtZweJKC6aQUFYACfetys jYJPq7Pj20zX4drsSbKsD/0=3D =3DG/6h =2D----END PGP SIGNATURE----- |
|
From: Joyce P. <tru...@ya...> - 2004-03-26 18:44:54
|
Hey guys, So we had a fabulous meeting Wednesday night, mostly focused on server improvements. My notes are appended. Old Mod-pubsubbers also had a chance to meet the fresh blood, Alex and Vishy and Henry, who are pushing the effort on behalf of Friendster. Next Wednesday, we will be meeting again -- this time, with a focus on the JavaScript client. I'm sure we'll also get some updates on progress made on the server-side. Hope to see you there! JP eplication Performance --memory --long queues (delivery bug) --select() --old event initial route population has a long pause --HTTP 1.1 --robust (lazy expiration) --topics never die --overhead for reaping Security --SSL --authentication --security --do_method=batch loses errors, error handling unspecified --sequencing (events have to be delivered in order) --auth/auth policy callbacks or hooks --e.g. unix-domain-sockets --disable introspection Latency Scalability --10K connections/box Failover --topic-based expiration policy --weak ref topic for route dest --lease-extension for expiring objects |
|
From: Asynch M. <asy...@ho...> - 2004-03-26 04:29:19
|
Okay - I think I figured it out. Either there is a latency, or I needed to purge my system & ensure the login is as a developer & not anonymous. Never mind. I see the new files... ----- Original Message ----- From: "Asynch Messaging" <asy...@ho...> To: <mod...@li...>; "Robert Leftwich" <ro...@le...> Sent: Wednesday, March 24, 2004 8:39 PM Subject: Re: [Mod-pubsub-developer] New Java client in CVS > I'm confused - I checked out the 'mod_pubsub' module but cannot see that > location. > What is the module name to use? > > Oh well. Anyway, I have a /separate/ client in > net.xmlrouter.mod_pubsub.client. > I'll be ripping off any event stream parsing improvements and dropping it in > there too... > > > ----- Original Message ----- > From: "Robert Leftwich" <ro...@le...> > To: <mod...@li...> > Sent: Wednesday, March 24, 2004 5:32 PM > Subject: [Mod-pubsub-developer] New Java client in CVS > > > > I've just put the new java client code in cvs. See > > java_pubsub/src/org/mod_pubsub/client for the code and > > java_pubsub/test/org/mod_pubsub/client for the unit tests. There's also a > > couple of new jars in the lib directory.. > > > > Still to be done: > > > > An ant build file (I've been using Eclipse up to now) > > More real-life functional testing > > Finish off Javadoc > > UTF-8 unit tests > > and some more things I've probably missed > > > > > > Longer term : > > > > Reconnection logic > > Off-line storage of events > > etc > > > > > > Robert > > > > > -------------------------------------------------------------------------- -- > ---- > > > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.634 / Virus Database: 406 - Release Date: 18/03/2004 > > > |
|
From: Asynch M. <asy...@ho...> - 2004-03-26 04:29:18
|
>
> >Oh well. Anyway, I have a /separate/ client in
> >net.xmlrouter.mod_pubsub.client.
>
> Have you checked it in?
Yeah - it's been there for quite a while & I updated it over the weekend &
tonight.
I finished some re-factoring. There are now some low level classes like
EventServer (just routes on remote server), Connection (handles journal
topic) and Dispatcher (routes incoming message to multiple listener objects
based on kn_routed_from).
There was already an EventStream which handled all the parsing by reading an
InputStream and a SimpleRouter that simplified doing simple things (which is
why it is simply named SimpleRouter).
There is some unfinished business with 'MessageInterceptor' that I'll
someday use to inject default headers (like username, etc) into outgoing
messages.
None of these have the rigorous testing that your packages have. The next
time I get some free time I'll add unit tests.
I also added a sample console app 'Snoop'.
try
{
SimpleRouter router = new SimpleRouter(args[0]);
DebugListener listener = new DebugListener();
router.subscribe(args[1],listener,null);
}
catch(Exception e)
{
System.err.println("ERROR: "+e.getMessage());
}
|
|
From: Robert L. <ro...@le...> - 2004-03-25 11:24:46
|
I've added an ant build file and a few changes to support disconnecting the underlying http connection, simple reconnection when publishing and better handling of problems, such as a server going missing. The ant build file can do the normal things such as clean, compile, run unit tests and build a jar containing all the non-test code. Robert |
|
From: Robert L. <ro...@le...> - 2004-03-25 05:12:27
|
At 03:39 PM 25/03/2004, Asynch Messaging wrote: >I'm confused - I checked out the 'mod_pubsub' module but cannot see that >location. >What is the module name to use? That's the right one. I think you are seeing the delay mentioned in the sf cvs intro: "There may be a delay of up to five hours between the time a developer commits a file and when it becomes available via pserver. " >Oh well. Anyway, I have a /separate/ client in >net.xmlrouter.mod_pubsub.client. Have you checked it in? >I'll be ripping off any event stream parsing improvements and dropping it in >there too... Variety is the spice of life. I was going to say that hopefully we'll end up with a unified approach, but on second thoughts it's not that vital and it may end up being more useful to more people. Robert |
|
From: Asynch M. <asy...@ho...> - 2004-03-25 04:39:58
|
I'm confused - I checked out the 'mod_pubsub' module but cannot see that location. What is the module name to use? Oh well. Anyway, I have a /separate/ client in net.xmlrouter.mod_pubsub.client. I'll be ripping off any event stream parsing improvements and dropping it in there too... ----- Original Message ----- From: "Robert Leftwich" <ro...@le...> To: <mod...@li...> Sent: Wednesday, March 24, 2004 5:32 PM Subject: [Mod-pubsub-developer] New Java client in CVS > I've just put the new java client code in cvs. See > java_pubsub/src/org/mod_pubsub/client for the code and > java_pubsub/test/org/mod_pubsub/client for the unit tests. There's also a > couple of new jars in the lib directory.. > > Still to be done: > > An ant build file (I've been using Eclipse up to now) > More real-life functional testing > Finish off Javadoc > UTF-8 unit tests > and some more things I've probably missed > > > Longer term : > > Reconnection logic > Off-line storage of events > etc > > > Robert > ---------------------------------------------------------------------------- ---- > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.634 / Virus Database: 406 - Release Date: 18/03/2004 > |
|
From: Robert L. <ro...@le...> - 2004-03-25 01:31:44
|
I've just put the new java client code in cvs. See
java_pubsub/src/org/mod_pubsub/client for the code and
java_pubsub/test/org/mod_pubsub/client for the unit tests. There's also a
couple of new jars in the lib directory..
Still to be done:
An ant build file (I've been using Eclipse up to now)
More real-life functional testing
Finish off Javadoc
UTF-8 unit tests
and some more things I've probably missed
Longer term :
Reconnection logic
Off-line storage of events
etc
Robert
|
|
From: Robert L. <ro...@le...> - 2004-03-25 01:20:49
|
At 11:46 AM 25/03/2004, Joyce Park wrote: >We could either call you if you provide a number, or use the chat. JP Calling is probably a little excessive, chat might be the go, if a little bandwidth limited. Hmm, you said you needed a whiteboard, do you have that hooked up to a mps server :-). Seriously, though, having me involved either by phone or chat might be too limiting on your flow. Lets play it by ear, (so to speak). I'll be monitoring chat, if there's anything you guys think I need to know/be involved in then let me know. Robert |
|
From: Joyce P. <tru...@ya...> - 2004-03-25 00:59:00
|
--- Robert Leftwich <ro...@le...> wrote: > > Conference me in using .... ? We could either call you if you provide a number, or use the chat. JP |
|
From: Robert L. <ro...@le...> - 2004-03-24 23:37:47
|
According to comments in the code and some inspection/testing, unsubscribe is not yet supported in the python server, is that correct? Is it supported in the Perl server and if so, is there a running server somewhere I can test against? Robert |
|
From: Robert L. <ro...@le...> - 2004-03-24 19:38:48
|
At 05:18 AM 25/03/2004, Joyce Park wrote: >It's CVS. Just check in. :-) I guess the major cvs thing I was concerned about was getting it in the right place, given sf's cvs' issues with deleting/moving directories. Currently, the code resides in the 'org.mod_pubsub.client' package and below (which translates to a /java_pubsub/src/org/mod_pubsub/client directory). Anyone have a problem with this? >Hey Robert... we're having a mod-pubsub meeting at my office tonight at 6:30 >Pacific time. Timeanddate.com suggests that this is like 1:30PM for you? If >so, we could conference you in! Let us know, JP Sounds good. Conference me in using .... ? Robert |
|
From: Joyce P. <tru...@ya...> - 2004-03-24 19:16:28
|
It's CVS. Just check in. :-) We make and release builds for public consumption on a longer schedule. And who among us would deem it worthy? It's not like we're exactly Java experts... except, maybe Mike. Hey Robert... we're having a mod-pubsub meeting at my office tonight at 6:30 Pacific time. Timeanddate.com suggests that this is like 1:30PM for you? If so, we could conference you in! Let us know, JP --- Robert Leftwich <ro...@le...> wrote: > At 09:08 AM 23/03/2004, I wrote: > > >All things going well I should have a useable release later today, but > >writing unit tests that cover all the edge cases is no small undertaking! > > Naturally, all things did not go well, so I didn't make that optimistic > deadline, but I will have a useable release ready shortly. The question > then arises, were should I put it? Should we make a sandbox in cvs to hold > code until it is deemed worthy of being included in the release? Some other > approach? |
|
From: Robert L. <ro...@le...> - 2004-03-24 18:08:17
|
At 09:08 AM 23/03/2004, I wrote: >All things going well I should have a useable release later today, but >writing unit tests that cover all the edge cases is no small undertaking! Naturally, all things did not go well, so I didn't make that optimistic deadline, but I will have a useable release ready shortly. The question then arises, were should I put it? Should we make a sandbox in cvs to hold code until it is deemed worthy of being included in the release? Some other approach? Robert |
|
From: Asynch M. <asy...@ho...> - 2004-03-24 06:42:09
|
Okay - I think I've missed something about CVS directories I have mod_pubsub/mod_pubsub/java_pubsub as a directory, but I also have just mod_pubsub/java_pubsub. I've been using mod_pubsub/java_pubsub for my edits, but I now see that this might be incorrect. What is the correct location to be using? |
|
From: Joyce P. <tru...@ya...> - 2004-03-24 01:54:17
|
I can drive people to the BART station in Millbrae afterwards, if that helps. If someone who works further north wants to suggest their office -- Tommy maybe? -- that would be cool with me. One problem is that we tend to schedule for the people we are SURE will be attending... so generally those who RSVP first will get to call the location. In this case I just wanted to have whiteboards, so I suggested my office... but I'm totally open to moving further north sometimes. JP --- Kragen Sitaker <kra...@ai...> wrote: > > I guess I can make it to Mountain View tomorrow; I'll check with Beatrice. > I hope we can find spots further north sometimes. (You know, you'd > think there would be an industry to support small ad-hoc meetings like > this, maybe costing --- like a restaurant --- $10-$20 per person --- > but I don't know about one.) |
|
From: Joyce P. <tru...@ya...> - 2004-03-24 01:48:38
|
Wow, people are so excited about mod-pubsub that we've decided to have not one but TWO meetings! There will be one tomorrow, and one a week hence. Yay! JP --- Joyce Park <tru...@ya...> wrote: > Sorry Adam, you'll have to leave early because tomorrow night is better for > the > group. I hope 6:30 is good for people. The address is 1380 Villa, and my > cellphone is 650-315-7241. See you tomorrow! JP |
|
From: Kragen S. <kra...@ai...> - 2004-03-24 01:36:46
|
On Tue, Mar 23, 2004 at 02:28:26PM -0800, Joyce Park wrote: > Sorry Adam, you'll have to leave early because tomorrow night is better for the > group. I hope 6:30 is good for people. The address is 1380 Villa, and my > cellphone is 650-315-7241. See you tomorrow! JP I guess I can make it to Mountain View tomorrow; I'll check with Beatrice. I hope we can find spots further north sometimes. (You know, you'd think there would be an industry to support small ad-hoc meetings like this, maybe costing --- like a restaurant --- $10-$20 per person --- but I don't know about one.) |
|
From: Joyce P. <tru...@ya...> - 2004-03-23 22:54:27
|
Sorry Adam, you'll have to leave early because tomorrow night is better for the group. I hope 6:30 is good for people. The address is 1380 Villa, and my cellphone is 650-315-7241. See you tomorrow! JP --- Joyce Park <tru...@ya...> wrote: > So it sounds like this Wednesday -- the day after tomorrow -- may be best for > Alex and Ben. Is that OK with everyone, or are there people who can make it > next Wednesday who cannot come this week? JP |
|
From: BC S. <bsi...@in...> - 2004-03-23 22:34:50
|
Actually the kn_response_format=simple encoding (used by all non-JavaScript client libraries) makes a special case for kn_payload, where the payload value is not encoded in any way -- i.e. it is sent as raw bytes after the other [encoded] headers and a newline. So none of the encoding rules (quoted-printable, etc.) apply to the kn_payload value, and there is no 'kn_payload: ...' in the headers. ----- Original Message ----- From: Kragen Sitaker <kra...@ai...> Date: Tue, 23 Mar 2004 11:47:35 -0800 To: Robert Leftwich <ro...@le...> Subject: Re: [Mod-pubsub-developer] Event element encoding > On Tue, Mar 23, 2004 at 09:08:20AM +1100, Robert Leftwich wrote: > > We might run into problems with Rule 4 of RFC 1521 which says "A line > > break in a text body, independent of what its representation is following > > the canonical representation of the data being encoded, must be represented > > by a (RFC 822) line break, which is a CRLF sequence...", but given the > > python server encodes \n it may not be an issue. > > Hmm, it's only in the Perl server's on-disk format that we leave newlines > in kn_payload unencoded, right? Nobody uses an on-the-wire format with > a special case for kn_payload? > > > The fact that the mps spec only uses the QP 'style', not the QP spec itself > > is a possible source of problems, so using a qp decode function is probably > > not ideal. Although, the likelihood of it causing any problems appears to > > be pretty low, as evidenced by the fact that no-one is reporting any actual > > problems! > > > > Do we keep the status quo and 'don't fix it if it ain't broke'? > > Maybe nobody's been testing most of the clients with, say, JPEG files > as event attributes. Maybe we should. > > > All things going well I should have a useable release later today, but > > writing unit tests that cover all the edge cases is no small undertaking! > > That's excellent! > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Mod-pubsub-developer mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-pubsub-developer -- _______________________________________________ Get your free email from http://www.iname.com |
|
From: Kragen S. <kra...@ai...> - 2004-03-23 19:47:47
|
On Tue, Mar 23, 2004 at 09:08:20AM +1100, Robert Leftwich wrote: > We might run into problems with Rule 4 of RFC 1521 which says "A line > break in a text body, independent of what its representation is following > the canonical representation of the data being encoded, must be represented > by a (RFC 822) line break, which is a CRLF sequence...", but given the > python server encodes \n it may not be an issue. Hmm, it's only in the Perl server's on-disk format that we leave newlines in kn_payload unencoded, right? Nobody uses an on-the-wire format with a special case for kn_payload? > The fact that the mps spec only uses the QP 'style', not the QP spec itself > is a possible source of problems, so using a qp decode function is probably > not ideal. Although, the likelihood of it causing any problems appears to > be pretty low, as evidenced by the fact that no-one is reporting any actual > problems! > > Do we keep the status quo and 'don't fix it if it ain't broke'? Maybe nobody's been testing most of the clients with, say, JPEG files as event attributes. Maybe we should. > All things going well I should have a useable release later today, but > writing unit tests that cover all the edge cases is no small undertaking! That's excellent! |
|
From: Joyce P. <tru...@ya...> - 2004-03-23 07:50:05
|
So it sounds like this Wednesday -- the day after tomorrow -- may be best for Alex and Ben. Is that OK with everyone, or are there people who can make it next Wednesday who cannot come this week? JP --- Adam Rifkin <ad...@xe...> wrote: > Anything works for me, preferably at a time when Ben, Kragen, > and Andrew can meet... |
|
From: BC S. <bsi...@in...> - 2004-03-23 02:35:39
|
You're right, it requires subscription rather than acting as an HTTP proxy. It allows you (for example) to subscribe a CGI script to a topic on the MPS server without keeping a long-running HTTP connection open. ----- Original Message ----- From: Kragen Sitaker <kra...@ai...> Date: Sun, 21 Mar 2004 14:43:12 -0800 To: BC Sittler <bsi...@in...> Subject: Re: [Mod-pubsub-developer] kn_from and kn_to > On Sun, Mar 21, 2004 at 02:23:17PM -0700, BC Sittler wrote: > > The Perl PubSub server already supports direct HTTP POST delivery of events > > to arbitrary URLs. This feature has not yet been implemented in the Python > > PubSub server, but perhaps it will be at some point. > > No, it doesn't --- it only supports indirect HTTP POST delivery to > arbitrary URLs, by means of a route. I don't know why you would want > your MPS server to support direct proxy HTTP POST. -- _______________________________________________ Get your free email from http://www.iname.com |
10 messages has been excluded from this view by a project administrator.
