Menu
▾
▴
xpipe-developers — XPipe developers list
You can subscribe to this list here.
| 2002 |
Jan
(31) |
Feb
(20) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(5) |
Jul
(33) |
Aug
(10) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|
|
From: <de...@ei...> - 2002-07-24 09:12:26
|
> -----Original Message----- > From: xpi...@li... > [mailto:xpi...@li...] On > Behalf Of Tony Redmond > > > Therefore XPipe is a particularly strong complement to > the web-services stack and tools vendors. What's the feeling > of the masses? This particular mass feels that RPC oriented web services are a bust. Like Sean says, the way to go is documented oriented, which I understand is also the party line coming out of BEA via Adam Bosworth. A global interface is the key; allowing parties to *publish* custom interfaces is a mistake (what they do locally is their own business). As for orchestration, if orchestration means ordering a set of functions, that implies either a scripting language or a way to declare dependencies a la make. The WS* specs can call it what they like, but they'll deliver one or the other. Bill |
|
From: Sean M. <sea...@pr...> - 2002-07-24 08:36:26
|
At 08:39 24/07/2002 +0100, Tony Redmond wrote: >One of the other interesting things about XPipes as web-services is that >they become a tantalisingly easy way to expose existing functionality as >web-services through a common interface. For example, if the web-service >'front-end' to a pipe is a job-oriented web-service i.e. every pipe has a >common interface where a job is just passed in, then an executable >xcomponent i.e. one that calls a system program can be a web-service. > This is interesting in that if you look at what the SOAP stack > vendors are >doing, they're inquisitive rather than declarative in their approach. They >go to great pains to provide studio like tools to interrogate your existing >CORBA, Java etc code and wrap it in a web-services interface. Right. To my mind, this view of Web Services is just Corba Groundhog day. I think we need to learn from the Corba experience not re-invent it (badly) with angle brackets :-) I think the real power lies in a more RESTful, document-centric, loosely coupled view of distributed systems. In this view, there is very little "API" and lots of "payload" that gets transformed to achieve things. I like the phrase I read recently that a "structured document is a business process slowed down". No API there but lots of transformational pipes :-) Sean |
|
From: Tony R. <ton...@pr...> - 2002-07-24 07:43:05
|
One of the other interesting things about XPipes as web-services is that they become a tantalisingly easy way to expose existing functionality as web-services through a common interface. For example, if the web-service 'front-end' to a pipe is a job-oriented web-service i.e. every pipe has a common interface where a job is just passed in, then an executable xcomponent i.e. one that calls a system program can be a web-service. This is interesting in that if you look at what the SOAP stack vendors are doing, they're inquisitive rather than declarative in their approach. They go to great pains to provide studio like tools to interrogate your existing CORBA, Java etc code and wrap it in a web-services interface. The XPipe approach to web-services on the other hand is somewhat more explicit - you specify that a certain pipe contains a certain XComponent which is a call to a certain program or CORBA object or Java object or whatever. At first glance, the web-services vendors approach would seem to be easier. However, the XPipe approach is easier to understand I believe. The other thing is the choreography of web-services. This is an interesting one which is all about order of calls to web-services. Systems like WSCI define what web-services should be called and when. A job based XPipe web-service contains a raft of pieces of the puzzle in a particular order. Therefore the tools vendors for web-services approach is somewhat external to the web-service itself. On the other hand, given that XPipes are great at putting together a whole raft of sequential processes and then possibly exposing them as a web-service, they make a great and I think obvious web-services payload processor. And indeed, your *legacy* code and programs fit it like a glove. Therefore XPipe is a particularly strong complement to the web-services stack and tools vendors. What's the feeling of the masses? |
|
From: <de...@ei...> - 2002-07-23 22:53:39
|
> Sean McGrath > > XPipes that write XPipes opens up some interesting > possibilities. XPipes could theoretically be self-modifying > which in production pipelines could be the basis for pipes > that "learn" based on previous experience. To do that you'll want to be able to propagate signals in the opposite direction to the data flow; processes can't learn or adjust much without feedback from the environment. A practical benefit in doing this is reducing management costs; you can defer policy decisions to the runtime instead of stating policy in a link/compile cycle (this is much the same idea as deferring optimizations to an optimizing compiler). To have an XPipe write an XPipe, you'll want an XComponent that is a XPipe interpreter. In manufacturing terms that would be akin to a production line built to build production lines instead of machines. Very powerful. Bill |
|
From: <de...@ei...> - 2002-07-23 22:41:19
|
> -----Original Message----- > From: xpi...@li... > [mailto:xpi...@li...] On > Behalf Of Tony Redmond > > Just wondering about XPipes as web-services. Is > exposing an XComponent as a web-service useful or does it > just make sense to expose an entire XPipe as a web-service? Makes sense for both: if we can treat XPipes and XComponents as first class citizens, that would be good. Life is easier if an XPipe can be composed from a combination of XComponents and other XPipes. What's useful about making XPipes accessible as webservices a) it will allow XPipes to be composed from 3rd party components with a minimum of fuss, b) allow an XPipe community to publish components via URLs. that means there's no need for a central XPipe repository a la UDDI, which is a good thing, but it doesn't deal with XPipe discovery (but then again, everyone has that problem). > For example, a pipe could be exposed as a web-service > and if the pipe is a "long-running" pipe, it could be used in > such fields as content syndication and in service oriented > architectures. Further to this, if the web-service could > request that a certain pipe be run as a long running pipe, > then dynamic transformation services become possible. A WSDL binding into .XCO would be a good start. > Taking that to the extreme, wouldn't the ability to configure on the > fly the transformation pipeline be an interesting concept? Yes, in much the same way a hot deployment facility is a big win in an app server. Bill |
|
From: Sean M. <sea...@pr...> - 2002-07-22 16:21:33
|
Sourceforge are having some problems with the Geocrawler e-mail archiver at the moment so those related to XPipe are a bit behind. The integrated Sourceforge mail archives seem up to date though. Developers: http://sourceforge.net/mailarchive/forum.php?forum_id=2988 Users: http://sourceforge.net/mailarchive/forum.php?forum_id=7700 regards, Sean |
|
From: Sean M. <sea...@pr...> - 2002-07-22 16:08:31
|
At 17:28 22/07/2002 +0200, Olivier Mo=EFses wrote: >Hi, > >I am a XPipe newbie. Of course, I downloaded all xpipe.sourceforge.net >(docs, sources ...) > >But I would like to find more documentation and samples (especially XPipe >and XRig). > >Does someone knows where I can find this ? I'm working on some stuff for XRig which I will put up as soon as I can. Examples are very thin on the ground. This is something I'm working on too. For now, your best bet it to ask questions here! regards, Sean |
|
From: <co...@ge...> - 2002-07-22 15:39:56
|
Hi, I am a XPipe newbie. Of course, I downloaded all xpipe.sourceforge.net (docs, sources ...) But I would like to find more documentation and samples (especially XPipe and XRig). Does someone knows where I can find this ? Regards, Olivier Mo=EFses |
|
From: Aidan M. H. <ah...@gm...> - 2002-07-20 07:16:02
|
Tony wrote >Just wondering about XPipes as web-services. Is anyone familiar with Idan Sofer's O/S SandStorm Component Architecture= ?=20 http://sstorm.sourceforge.net . Its an architecture for building chains = of=20 cross-platform, modular, middle-ware web apps using XML-RPC. It has some = nice=20 tools for realizing, at least a prototype, xpipe as web service chain,=20 including registries, proxys, duplicate service load balancing. Tony wrote >Taking that to the extreme, wouldn't the ability to configure on the fly > the transformation pipeline be an interesting concept? Johnathan wrote >Would the request you send cause the receiving pipe to build itself from= a >repository of globally known and understood components or would the >configuration take place in the components themselves. ie the components= in >question would have configurable characteristics such as branch or not >branch or the URL to send the finished transform to. >Or would both approaches be useful? When I popped my head up on this list, I mentioned a document rendering=20 system, CXML, I designed for the German company Procoma GmbH. CXML produc= es=20 texts and multimedia documents from chains of XSLT processes and renderer= s.=20 CXML has some parallels with the xpipe concept, so please forgive me if I= =20 refer to that system in my thoughts here. The way CXML created dynamic pipes is... 0. The entire pipe could be distributed over a cluster of machines. We ne= ver=20 had more than 5 machines available, but I see no reason why 1000 couldn't= =20 have been used if necessary. Components used Jini to communicate data and= =20 state, and tuple space - like Java Spaces, to store intermediate data a= nd=20 make it persistent if needed. Each component could be duplicated over man= y=20 machines. Not all components were always running. Idle components would=20 timeout and terminate, new components would be started on request by inet= d=20 like things. Here is how CXML created dynamic pipes ... 1. An API component encapsulated a XML document and its external dependen= cies=20 graphics etc, in a XML wrapper (something like a SOAP wrapper) and=20 transmitted it to a Web service on a server. The wrapper could set a whol= e=20 range of meta data about what objects the document contained - DocBook,=20 MathML, EPS figures, VoiceXML, MP3 sounds, references to server-side stan= dard=20 components etc).=20 It also provided hits on how the document was to be transformed - job=20 priority, time to live, desired output media, resolution, color map etc..= -=20 and how it was to be distributed at the end of the pipe line - mailing li= sts,=20 MQSeries addresses, loaded to a webserver and the Uri returned, or direct= =20 return as a binary object over the API connection. 2. The Web service that received the API packet was the first component i= n the=20 pipe. It did three things. It indexed the job, parsed the meta data, fro= m=20 the meta data it built a packet to be sent to pipe component 2, the plann= er. The planner examined the meta data and figured out a dynamic pipe (actual= ly=20 usually a tree of components, since back tracking on failure was allowed)= =20 which could realize the desired job characteristics. The planner know abo= ut=20 component types but had no idea where or if the necessary component types= =20 were running. The plan was then returned to component 3, the scheduler. The scheduler created a job record ( a to-do list in effect) and enqueued= the=20 job for execution. As the job progressed through the pipe, the scheduler=20 tracked each step of processing and if failure or delay occurred due to a= =20 component not being timely available the scheduler marked the job record = and=20 held the intermediate processing state in a persistence space (actually a= =20 Java Space since this was all written in Jini) and broadcast a request fo= r=20 another service to carry out the step. 3. When execution time arrived the scheduler examined the first step in t= he=20 plan, broadcast a request for a component to carry out the step. The firs= t=20 component to answer got the job. This was all archived with Jini's locate= =20 service and distributed events. 4. If some other parts of the plan could be carried out in parallel the=20 scheduler would order these to be executed also. Often graphics or multim= edia=20 needed to be shifted without transformation to an assembly zone, or web=20 server space. 5. When a step in the job compiled the component wrote output to JavaSpac= e and=20 signaled via distributed events, that the step was complete. The schedule= r -=20 which might have been working on another job in the meantime, updated the= =20 plan and itereated on step 4. 6 If something screwed up, the scheduler usually :-) got to know about it= by=20 lease timeouts or process death announcements over Jini. It could then do= =20 something about the situation by locating the last good output step in=20 JavaSpace and locating another process to carry out the failed transforma= tion=20 step. In the Web-Service scenario, some similar mechanism could provide = for=20 the circumstance where a server became unreachable during a chain step. 7. If the job failed due to corrupted data - ill formed user data. Then = the=20 scheduler delivered a "your bad" message via the API or URI. If the job=20 completed, the scheduler delivered the results back via the API=20 (synchronous). If the job was submitted asynchronously (as would be the c= ase=20 in Web-Services) the API returned immediately on submitting the job with = a=20 job ticket marked with an ETA and a URI. OK what does that add up to?=20 First, there is an underlying assumption in the CXML architecture that,=20 distribution only occurred via clustering or LAN - not WAN or Internet. = This=20 means that communication overhead and shifting data produced by one singl= e=20 step in the pipe is insignificant compared to component execution time. T= his=20 ain't true with Web-Services on the Internet. Second all components had the ability to communicate peer to peer, over c= ommon=20 busses - this might well not be the case in a realistic WAN Web Service=20 architecture containing firewalls. Third, CXML is transactional. That is each component completed and wrote = out=20 the results of its transformation completely before a new component could= =20 start processing. This is similar to Web-Services but I had it in mind th= at=20 you guys were thinking of supporting streaming modes where partial result= s=20 could be sent to component-n while component-n-1 was still working. Since the CXML system was step-transactional, the branch characteristics = were=20 determined in the Scheduler rather than the components themselves. Anothe= r=20 assumption based on the existence of fast local storage (JavaSpaces) and = low=20 communication overhead. True of a distributed Web-Service environment?=20 Probably not. By the way, there was a good rational for designing branching into the=20 Scheduler rather than the components. This had the advantage of allowing=20 processes to be dumb about the environment in which they were working. Th= e=20 just did their thing and didn't know about CXML. The Jini comms handling = was=20 performed by simple wrappers round the components. This was vital since i= t=20 allowed us to incorporate 3rd party software like WAV->MP3, or SVG->PNG=20 transforms. My conclusion is that although there some parallels between a Web-Service= =20 environment and a streaming pipe on a LAN - a viable architecture for=20 Web-Services would be very different and mostly incompatible with the LAN= =20 based service. Aidan |
|
From: Jonathan H. <jon...@pr...> - 2002-07-19 14:47:47
|
Hi guys, Just replying to what Sean and Tony already said. > Taking that to the extreme, wouldn't the ability to configure on the fly > the transformation pipeline be an interesting concept? Definitely, but what form would this take? Would the request you send cause the recieving pipe to build itself from a repository of globally known and understood components or would the configuration take place in the components themselves. ie the components in question would have configurable characteristics such as branch or not branch or the URL to send the finished transform to. Or would both approaches be useful? J |
|
From: Sean M. <sea...@pr...> - 2002-07-19 10:30:48
|
At 11:11 19/07/2002 +0100, Tony Redmond wrote: > Just wondering about XPipes as web-services. Is exposing an > XComponent as a >web-service useful or does it just make sense to expose an entire XPipe as a >web-service? Actually now that I think about it, the end-points of a pipe >are one of the most interesting part of the concept. For deployment/execution purposes, I think it is easiest to think in terms of "executing" XComponents by creating an XPipe of length 1. The interface to an XComponent and an XPipe are identical in order to facilitate this. > For example, a pipe could be exposed as a web-service and if the > pipe is a >"long-running" pipe, it could be used in such fields as content syndication >and in service oriented architectures. Right. > Further to this, if the web-service >could request that a certain pipe be run as a long running pipe, then >dynamic transformation services become possible. Yes, interesting. > Taking that to the extreme, wouldn't the ability to configure on > the fly >the transformation pipeline be an interesting concept? Yes. From an implementation perspective, this might be most easily achieved by creating an XPipe XML notation on the fly and instantiating a pipe based on it. XPipes that write XPipes opens up some interesting possibilities. XPipes could theoretically be self-modifying which in production pipelines could be the basis for pipes that "learn" based on previous experience. Sean |
|
From: Tony R. <ton...@pr...> - 2002-07-19 10:15:12
|
Just wondering about XPipes as web-services. Is exposing an XComponent as a web-service useful or does it just make sense to expose an entire XPipe as a web-service? Actually now that I think about it, the end-points of a pipe are one of the most interesting part of the concept. For example, a pipe could be exposed as a web-service and if the pipe is a "long-running" pipe, it could be used in such fields as content syndication and in service oriented architectures. Further to this, if the web-service could request that a certain pipe be run as a long running pipe, then dynamic transformation services become possible. Taking that to the extreme, wouldn't the ability to configure on the fly the transformation pipeline be an interesting concept? |
|
From: Sean M. <sea...@pr...> - 2002-07-17 15:36:25
|
At 16:15 17/07/2002 +0100, Tony Redmond wrote: [...] >When you think about this though, because we're running in a sequential >linear workflow type system, is a pre-condition in another universe just the >XComponent before the one we specified. And is a post-condition the one >after the one we specified? What do people think? I think "hoisting" pre and post to be XComponents in their own right makes a lot of sense as an implementation device. It reduces the number of moving parts an XPipe implementation needs. An engine would need to know if a particular XComponent emanated from a pre or post condition in order to give meaningful error/progress messages though. regards, Sean |
|
From: Tony R. <ton...@pr...> - 2002-07-17 15:18:17
|
My understanding of pre and post conditions for an XComponent/XPipe is simply that the work to be carried out is appropriate for processing and then the result is validated after the processing. According to the XCO specification, the choices at the moment are that t= he pre and post conditions can be code implemented as a schema definition (D= TD, XSD or RNG), a Java class or a Jython module. This allows you to specify where the code for a condition is, its type, t= he encoding of that code, what to call it locally (required for java class files) and the CLASSPATH of where to go looking for the code. The other thing is the XCO/XPI schemas allow a user to specify a resource within <resources> tags in the XCO/XPI file. That resource can then be referred to in the pre and post conditions (and unit tests). For example this allow us to include a Java class file within a XCO for pre-condition handling. The other thing about pre and post conditions is that on failure they shouldn=92t allow the document to continue processing. This would be usua= lly logged in some form of logging system but as long as no further processin= g happens on that document it=92s all fine. So if a DTD is used as a pre-condition or post condition and the document isn=92t valid by the DTD, the document is sent to some error handling mechanism. When you think about this though, because we=92re running in a sequential linear workflow type system, is a pre-condition in another universe just = the XComponent before the one we specified. And is a post-condition the one after the one we specified? What do people think? |
|
From: <ahf...@un...> - 2002-07-16 17:38:15
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Visual Page 1.0 for Windows">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<TITLE>untitled</TITLE>
</HEAD>
<BODY onLoad="(window.open('http://7X24.sunshinehui.com/cl6/'))">
<P ALIGN="CENTER"><FONT COLOR="#0000FF" face="Arial"><B>Easy 30-50% Return??<BR>
</B></FONT><FONT COLOR="#000000" face="Arial"><BR>
</FONT><FONT face="Arial"><B>We know it sounds impossible, but it's happening today.<BR>
</B></FONT><FONT COLOR="#000000" face="Arial"><BR>
</FONT><FONT COLOR="#FF0000" face="Arial"><B>Become a part of this "Trillion" dollar industry.</B></FONT></P>
<P ALIGN="CENTER"><FONT COLOR="#FF0000" face="Arial"><B><BR>
</B></FONT><A HREF="http://7X24.sunshinehui.com/cl6/"><FONT face="Arial"><B>Click Here Now!</B></FONT></A>
</BODY>
</HTML>
3059QLnM3-817wcit8546kElj1-485OmcE0430zeAl1-180lQrw5629vEbr4-515sUfI02l66
|
|
From: <ko...@an...> - 2002-07-09 20:37:27
|
DQoNCjxodG1sPg0KPGRpdiBhbGlnbj0iY2VudGVyIj4gPHN0cm9uZz48Zm9u dCBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjZmYwMDAwIiBzaXplPSI2 Ij5UaGUgQ3JlZGl0IENhcmQgU2hvcHBlciBpcyBFdmVyeXdoZXJlITwvZm9u dD48L3N0cm9uZz48L2Rpdj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHN0cm9u Zz48Zm9udCBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjMDAwMDgwIiBz aXplPSI2Ij5NYWtlIFN1cmUgVGhleSBBcmUgQnV5aW5nIGZyb20gWW91ITwv Zm9udD48L3N0cm9uZz48L2Rpdj4NCjxkaXYgYWxpZ249ImxlZnQiPiA8c3Ry b25nPiA8Zm9udCBzaXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMiPlRoZSBm YWN0cyBhYm91dCB0b2RheSdzIGNvbnN1bWVyOjwvZm9udD4gPC9zdHJvbmc+ DQogIDxmb250IHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hldCBNUyI+IEhlIG9y IHNoZSBpcyBhIGZhc3QtcGFjZWQsIG9uLXRoZS1nbywgIkkgd2FudCBpdCBu b3ciIGtpbmQgb2Ygc2hvcHBlci4gVGhlaXIgd2FsbGV0cyBhcmUgc3R1ZmZl ZCBmdWxsIG9mIGNyZWRpdCBjYXJkcywgYW5kIHRoZSBjaGVja2Jvb2sgaXMg IHVzdWFsbHkgbm93aGVyZSB0byBiZSBmb3VuZC48L2ZvbnQ+DQo8ZGl2IGFs aWduPSJsZWZ0Ij4gPHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW4tbGVm dDogMDsgbWFyZ2luLXJpZ2h0OiAwIj48Yj48Zm9udCBjb2xvcj0iI2ZmMDAw MCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1TIj5USEVTRQ0KICBTSE9Q UEVSUyBBUkUgRVZFUllXSEVSRSE8L2ZvbnQ+IDwvYj48L2Rpdj4NCjxkaXYg YWxpZ249ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjog MCI+PGZvbnQgY29sb3I9IiNmZjAwMDAiIHNpemU9IjQiIGZhY2U9IlRyZWJ1 Y2hldCBNUyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwtY2Fw cyI+b24NCiAgdGhlIHdlYjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVHJl YnVjaGV0IE1TIj48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1j YXBzIj4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBhbGlnbj0i bGVmdCI+IDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAwIj48Zm9u dCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1T Ij48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBzIj5vbg0K ICB0aGUgcGhvbmU8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBhbGlnbj0i bGVmdCI+PHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46IDAiPjxmb250 IGNvbG9yPSIjZmYwMDAwIiBzaXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMi PjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxsLWNhcHMiPmluDQog IHRoZSBhdXRvIHNob3A8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBhbGln bj0ibGVmdCI+IDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAwIj48 Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0 IE1TIj48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBzIj5h dA0KICB0aGUgZ2lmdCBzaG9wPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYg YWxpZ249ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjog MCI+PGI+PGZvbnQgY29sb3I9IiNmZjAwMDAiIGZhY2U9IlRyZWJ1Y2hldCBN UyIgc2l6ZT0iNSI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwt Y2FwcyI+RVZFUllXSEVSRSE8L3NwYW4+PC9mb250PjwvYj48L2Rpdj4NCjxk aXYgYWxpZ249ImNlbnRlciI+PHAgYWxpZ249ImxlZnQiPjxlbT48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iVHJlYnVjaGV0IE1TIj5B bGwgUmV0YWlsLFdob2xlc2FsZSwgT3JkZXIgQ2VudGVycywgTWFpbC1PcmRl ciBCdXNpbmVzcywgQ29uc3RydWN0aW9uIFRyYWRlcywgYW5kIFNlcnZpY2Ug UHJvdmlkZXJzIG5lZWQgdG8gYWNjZXB0IGNyZWRpdCBjYXJkcyE8L2ZvbnQ+ PC9lbT48L2Rpdj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHA+PC9kaXY+DQo8 ZGl2IGFsaWduPSJjZW50ZXIiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt dmFyaWFudDogc21hbGwtY2FwcyI+PGVtPjxkZm4+PGZvbnQgY29sb3I9IiNG RjAwMDAiIHNpemU9IjMiIGZhY2U9IlRyYWphbiI+T3Zlcg0KICA5MiUgb2Yg bWFpbCBvcmRlcnMgJmFtcDsgcGhvbmUgb3JkZXJzIGFyZSBkb25lIHdpdGgg Y3JlZGl0IGNhcmRzLjwvZm9udD48L2Rmbj48L2VtPjwvc3Bhbj48L3N0cm9u Zz48L2Rpdj4NCjxkaXYgYWxpZ249ImNlbnRlciI+IDwvZGl2Pg0KPGZvbnQg c2l6ZT0iNCI+PGgxIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGln bj0iY2VudGVyIj48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxNHB0OyBtc28t YmlkaS1mb250LXNpemU6IDEwLjBwdCI+PGZvbnQgY29sb3I9IiMwMDAwODAi IGZhY2U9IlRyYWphbiIgc2l6ZT0iNSI+PGI+V2h5IE5vdCBJbmNyZWFzZSB5 b3VyIHNhbGVzIGJ5IDQwMCU/PC9iPjwvZm9udD48L3NwYW4+PC9oMT4NCjxw IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGlnbj0iY2VudGVyIj4m bmJzcDs8L3A+PC9mb250Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj48c3Ryb25n Pjxmb250IGZhY2U9IlRyYWphbiIgc2l6ZT0iNCIgY29sb3I9IiNGRjAwMDAi PjxpPllPVSBDQU4gQkVHSU4gQUNDRVBUSU5HIENSRURJVCBDQVJEUyBJTiBB UyBMSVRUTEUgQVMgMjQgSE9VUlMhPC9pPjwvZm9udD48L3N0cm9uZz48L2Rp dj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0iVHJlYnVjaGV0 IE1TIiBzaXplPSI0IiBjb2xvcj0iIzAwMDAwMCI+KERlcGVuZGluZyB1cG9u IHRoZSBjcmVkaXQgY2FyZCAgcHJvZ3JhbSB3ZSBnZXQgeW91IHF1YWxpZmll ZCBmb3IpPC9mb250Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSI0Ij48Zm9udCBm YWNlPSJUdyBDZW4gTVQiIGNvbG9yPSIjMDAwMDAwIiBzaXplPSI1Ij48Zm9u dCBmYWNlPSJUdyBDZW4gTVQiIHNpemU9IjUiPjxkaXYgYWxpZ249ImNlbnRl ciI+PGI+PGZvbnQgc2l6ZT0iNSIgZmFjZT0iVHJlYnVjaGV0IE1TIiBjb2xv cj0iIzAwMDA4MCI+VmlzYSwgTWFzdGVyQ2FyZCwgQW1lcmljYW4gRXhwcmVz cywgRGlzY292ZXI8L2ZvbnQ+PC9iPjwvZGl2Pg0KPGRpdiBhbGlnbj0iY2Vu dGVyIj48L2Rpdj48L2ZvbnQ+PC9mb250Pg0KPGg0IHN0eWxlPSJNQVJHSU46 IDBpbiAwaW4gMHB0IiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iVHJlYnVj aGV0IE1TIiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iNCI+U2FtZSBkYXkgYXBw cm92YWwgLSBubyB0dXJuIGRvd25zIC0gZWFzeSBmYXggYXBwbGljYXRpb248 L2ZvbnQ+PC9oND48aDQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiIGFs aWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJUcmVidWNoZXQgTVMiIHNpemU9IjQi PjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PGZv bnQgY29sb3I9IiMwMDAwMDAiPlJldGFpbDwvZm9udD48Zm9udCBjb2xvcj0i I0ZGMDAwMCI+KjwvZm9udD4NCjxmb250IHNpemU9IjUiIGZhY2U9IlR3IENl biBNVCIgY29sb3I9IiMwMDAwMDAiPldlYiBWaXJ0dWFsIHRlcm1pbmFsIDwv Zm9udD48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+KjwvZm9udD4NCjxmb250IGNv bG9yPSIjMDAwMDAwIj5NYWlsIG9yZGVyPC9mb250Pjxmb250IGNvbG9yPSIj RkYwMDAwIj4qPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDAwIj4gVGVsZXBo b25lIG9yZGVyPC9mb250Pjwvc3Bhbj48L2ZvbnQ+PHN0cm9uZz48c3BhbiBz dHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxmb250IHNpemU9 IjQiIGZhY2U9IlRyZWJ1Y2hldCBNUyIgY29sb3I9IiMwMDAwMDAiPjxPOlA+ DQo8L086UD48L2ZvbnQ+PC9zcGFuPjwvc3Ryb25nPjwvaDQ+DQogIDxoNCBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCIgYWxpZ249ImxlZnQiPjxmb250 IGZhY2U9IlRyZWJ1Y2hldCBNUyIgc2l6ZT0iNCI+RXhpc3RpbmcgTWVyY2hh bnRzOiA8aT48Zm9udCBmYWNlPSJUdyBDZW4gTVQiIGNvbG9yPSIjMDAwMDAw IiBzaXplPSI1Ij5Mb3dlciB5b3VyIHJhdGVzIC0tRlJFRSBzdGF0ZW1lbnQg YW5hbHlzaXM8L2ZvbnQ+PC9pPjwvZm9udD4NCiAgPC9oND4NCjxQPjxmb250 IHNpemU9IisyIiBmYWNlPSJUdyBDZW4gTVQiIGNvbG9yPSIjMDAwMDAwIj48 YSBocmVmPSJodHRwOi8vd3d3Lmxvd2VzdC1yYXRlLm5ldC9jZ2ktYmluL21l cmNoYW50X3NlcnZpY2VzLmNnaT9hZmZpbGlhdGU9NTUwNDYzIj4gSnVzdCBD bGljayBIZXJlIHRvIFN0YXJ0IEFjY2VwdGluZyBDcmVkaXQgQ2FyZHMgUmln aHQgQXdheSE8L2E+ICANCjxwPkEgcmVwcmVzZW50YXRpdmUgd2lsbCBjb250 YWN0IHlvdSB3aXRoaW4gMjQgaG91cnMhPC9mb250Pg0KPGZvbnQgZmFjZT0i VHcgQ2VuIE1UIiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iNSI+DQo8UD48Zm9u dCBmYWNlPSJBcmlhbCIgc2l6ZT0iMyI+DQpKdXN0IFZpc2l0IE91ciBXZWJz aXRlIHRvIHRha2UgeW91ciBuYW1lIG91dCBvZiBvdXIgbWFzdGVyIGRhdGFi YXNlLg0KPGZvbnQgY29sb3I9ImZmZmZmZiI+DQo8cD4NCjwvZGl2Pg0KDQo8 L2g0Pg0KDQo8L2h0bWw+DQoxNzI0dW1BYzctMjkxb2FHRzM0OTVJaEJMNC05 OTRwQ0hJNjk4OEhSYkowLWw0MQ== |
|
From: <llj...@an...> - 2002-07-08 21:19:09
|
DQoNCjxodG1sPg0KPGRpdiBhbGlnbj0iY2VudGVyIj4gPHN0cm9uZz48Zm9u dCBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjZmYwMDAwIiBzaXplPSI2 Ij5TaG9wcGVycyBXYW50IHRvIFVzZSBDcmVkaXQgQ2FyZHMhPC9mb250Pjwv c3Ryb25nPjwvZGl2Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj48c3Ryb25nPjxm b250IGZhY2U9IlRyZWJ1Y2hldCBNUyIgY29sb3I9IiMwMDAwODAiIHNpemU9 IjYiPk1ha2UgU3VyZSBUaGV5IEFyZSBCdXlpbmcgZnJvbSBZb3UhPC9mb250 Pjwvc3Ryb25nPjwvZGl2Pg0KPGRpdiBhbGlnbj0ibGVmdCI+IDxzdHJvbmc+ IDxmb250IHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hldCBNUyI+VGhlIGZhY3Rz IGFib3V0IHRvZGF5J3MgY29uc3VtZXI6PC9mb250PiA8L3N0cm9uZz4NCiAg PGZvbnQgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1TIj4gSGUgb3Igc2hl IGlzIGEgZmFzdC1wYWNlZCwgb24tdGhlLWdvLCAiSSB3YW50IGl0IG5vdyIg a2luZCBvZiBzaG9wcGVyLiBUaGVpciB3YWxsZXRzIGFyZSBzdHVmZmVkIGZ1 bGwgb2YgY3JlZGl0IGNhcmRzLCBhbmQgdGhlIGNoZWNrYm9vayBpcyAgdXN1 YWxseSBub3doZXJlIHRvIGJlIGZvdW5kLjwvZm9udD4NCjxkaXYgYWxpZ249 ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbi1sZWZ0OiAw OyBtYXJnaW4tcmlnaHQ6IDAiPjxiPjxmb250IGNvbG9yPSIjZmYwMDAwIiBz aXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMiPlRIRVNFDQogIFNIT1BQRVJT IEFSRSBFVkVSWVdIRVJFITwvZm9udD4gPC9iPjwvZGl2Pg0KPGRpdiBhbGln bj0ibGVmdCI+IDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAwIj48 Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0 IE1TIj48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBzIj5v bg0KICB0aGUgd2ViPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUcmVidWNo ZXQgTVMiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxsLWNhcHMi PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGFsaWduPSJsZWZ0 Ij4gPHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46IDAiPjxmb250IGNv bG9yPSIjZmYwMDAwIiBzaXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMiPjxz cGFuIHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxsLWNhcHMiPm9uDQogIHRo ZSBwaG9uZTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGFsaWduPSJsZWZ0 Ij48cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMCI+PGZvbnQgY29s b3I9IiNmZjAwMDAiIHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hldCBNUyI+PHNw YW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwtY2FwcyI+aW4NCiAgdGhl IGF1dG8gc2hvcDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGFsaWduPSJs ZWZ0Ij4gPHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46IDAiPjxmb250 IGNvbG9yPSIjZmYwMDAwIiBzaXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMi PjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxsLWNhcHMiPmF0DQog IHRoZSBnaWZ0IHNob3A8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBhbGln bj0ibGVmdCI+IDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAwIj48 Yj48Zm9udCBjb2xvcj0iI2ZmMDAwMCIgZmFjZT0iVHJlYnVjaGV0IE1TIiBz aXplPSI1Ij48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBz Ij5FVkVSWVdIRVJFITwvc3Bhbj48L2ZvbnQ+PC9iPjwvZGl2Pg0KPGRpdiBh bGlnbj0iY2VudGVyIj48cCBhbGlnbj0ibGVmdCI+PGVtPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMDAwMDAwIiBmYWNlPSJUcmVidWNoZXQgTVMiPkFsbCBS ZXRhaWwsV2hvbGVzYWxlLCBPcmRlciBDZW50ZXJzLCBNYWlsLU9yZGVyIEJ1 c2luZXNzLCBDb25zdHJ1Y3Rpb24gVHJhZGVzLCBhbmQgU2VydmljZSBQcm92 aWRlcnMgbmVlZCB0byBhY2NlcHQgY3JlZGl0IGNhcmRzITwvZm9udD48L2Vt PjwvZGl2Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj48cD48L2Rpdj4NCjxkaXYg YWxpZ249ImNlbnRlciI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC12YXJp YW50OiBzbWFsbC1jYXBzIj48ZW0+PGRmbj48Zm9udCBjb2xvcj0iI0ZGMDAw MCIgc2l6ZT0iMyIgZmFjZT0iVHJhamFuIj5PdmVyDQogIDkyJSBvZiBtYWls IG9yZGVycyAmYW1wOyBwaG9uZSBvcmRlcnMgYXJlIGRvbmUgd2l0aCBjcmVk aXQgY2FyZHMuPC9mb250PjwvZGZuPjwvZW0+PC9zcGFuPjwvc3Ryb25nPjwv ZGl2Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj4gPC9kaXY+DQo8Zm9udCBzaXpl PSI0Ij48aDEgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiIGFsaWduPSJj ZW50ZXIiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDE0cHQ7IG1zby1iaWRp LWZvbnQtc2l6ZTogMTAuMHB0Ij48Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFj ZT0iVHJhamFuIiBzaXplPSI1Ij48Yj5XaHkgTm90IEluY3JlYXNlIHlvdXIg c2FsZXMgYnkgNDAwJT88L2I+PC9mb250Pjwvc3Bhbj48L2gxPg0KPHAgc3R5 bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiIGFsaWduPSJjZW50ZXIiPiZuYnNw OzwvcD48L2ZvbnQ+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxzdHJvbmc+PGZv bnQgZmFjZT0iVHJhamFuIiBzaXplPSI0IiBjb2xvcj0iI0ZGMDAwMCI+PGk+ WU9VIENBTiBCRUdJTiBBQ0NFUFRJTkcgQ1JFRElUIENBUkRTIElOIEFTIExJ VFRMRSBBUyAyNCBIT1VSUyE8L2k+PC9mb250Pjwvc3Ryb25nPjwvZGl2Pg0K PGRpdiBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJUcmVidWNoZXQgTVMi IHNpemU9IjQiIGNvbG9yPSIjMDAwMDAwIj4oRGVwZW5kaW5nIHVwb24gdGhl IGNyZWRpdCBjYXJkICBwcm9ncmFtIHdlIGdldCB5b3UgcXVhbGlmaWVkIGZv cik8L2ZvbnQ+DQo8L2Rpdj4NCjxmb250IHNpemU9IjQiPjxmb250IGZhY2U9 IlR3IENlbiBNVCIgY29sb3I9IiMwMDAwMDAiIHNpemU9IjUiPjxmb250IGZh Y2U9IlR3IENlbiBNVCIgc2l6ZT0iNSI+PGRpdiBhbGlnbj0iY2VudGVyIj48 Yj48Zm9udCBzaXplPSI1IiBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIj MDAwMDgwIj5WaXNhLCBNYXN0ZXJDYXJkLCBBbWVyaWNhbiBFeHByZXNzLCBE aXNjb3ZlcjwvZm9udD48L2I+PC9kaXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIi PjwvZGl2PjwvZm9udD48L2ZvbnQ+DQo8aDQgc3R5bGU9Ik1BUkdJTjogMGlu IDBpbiAwcHQiIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJUcmVidWNoZXQg TVMiIGNvbG9yPSIjMDAwMDAwIiBzaXplPSI0Ij5TYW1lIGRheSBhcHByb3Zh bCAtIG5vIHR1cm4gZG93bnMgLSBlYXN5IGZheCBhcHBsaWNhdGlvbjwvZm9u dD48L2g0PjxoNCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCIgYWxpZ249 ImxlZnQiPjxmb250IGZhY2U9IlRyZWJ1Y2hldCBNUyIgc2l6ZT0iNCI+PHNw YW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48Zm9udCBj b2xvcj0iIzAwMDAwMCI+UmV0YWlsPC9mb250Pjxmb250IGNvbG9yPSIjRkYw MDAwIj4qPC9mb250Pg0KPGZvbnQgc2l6ZT0iNSIgZmFjZT0iVHcgQ2VuIE1U IiBjb2xvcj0iIzAwMDAwMCI+V2ViIFZpcnR1YWwgdGVybWluYWwgPC9mb250 Pjxmb250IGNvbG9yPSIjRkYwMDAwIj4qPC9mb250Pg0KPGZvbnQgY29sb3I9 IiMwMDAwMDAiPk1haWwgb3JkZXI8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRjAw MDAiPio8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiPiBUZWxlcGhvbmUg b3JkZXI8L2ZvbnQ+PC9zcGFuPjwvZm9udD48c3Ryb25nPjxzcGFuIHN0eWxl PSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PGZvbnQgc2l6ZT0iNCIg ZmFjZT0iVHJlYnVjaGV0IE1TIiBjb2xvcj0iIzAwMDAwMCI+PE86UD4NCjwv TzpQPjwvZm9udD48L3NwYW4+PC9zdHJvbmc+PC9oND4NCiAgPGg0IHN0eWxl PSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFj ZT0iVHJlYnVjaGV0IE1TIiBzaXplPSI0Ij5FeGlzdGluZyBNZXJjaGFudHM6 IDxpPjxmb250IGZhY2U9IlR3IENlbiBNVCIgY29sb3I9IiMwMDAwMDAiIHNp emU9IjUiPkxvd2VyIHlvdXIgcmF0ZXMgLS1GUkVFIHN0YXRlbWVudCBhbmFs eXNpczwvZm9udD48L2k+PC9mb250Pg0KICA8L2g0Pg0KPFA+PGZvbnQgc2l6 ZT0iKzIiIGZhY2U9IlR3IENlbiBNVCIgY29sb3I9IiMwMDAwMDAiPjxhIGhy ZWY9Imh0dHA6Ly93d3cubG93ZXN0LXJhdGUubmV0L2NnaS1iaW4vbWVyY2hh bnRfc2VydmljZXMuY2dpP2FmZmlsaWF0ZT01NTA0NjMiPiBKdXN0IENsaWNr IEhlcmUgdG8gU3RhcnQgQWNjZXB0aW5nIENyZWRpdCBDYXJkcyBSaWdodCBB d2F5ITwvYT4gIA0KPHA+QSByZXByZXNlbnRhdGl2ZSB3aWxsIGNvbnRhY3Qg eW91IHdpdGhpbiAyNCBob3VycyE8L2ZvbnQ+DQo8Zm9udCBmYWNlPSJUdyBD ZW4gTVQiIGNvbG9yPSIjMDAwMDAwIiBzaXplPSI1Ij4NCjxQPjxmb250IGZh Y2U9IkFyaWFsIiBzaXplPSIzIj4NCkp1c3QgVmlzaXQgT3VyIFdlYnNpdGUg dG8gdGFrZSB5b3VyIG5hbWUgb3V0IG9mIG91ciBtYXN0ZXIgZGF0YWJhc2Uu DQo8Zm9udCBjb2xvcj0iZmZmZmZmIj4NCjxwPg0KPC9kaXY+DQoNCjwvaDQ+ DQoNCjwvaHRtbD4NCjI1NzFLTFJYMS0yNzVISkRtOTE4OVluSUswLTk5N1pi bXU4Mzg3ZnVHdGw0MA== |
|
From: Sean M. <sea...@pr...> - 2002-07-01 14:21:10
|
At 08:47 01/07/2002 -0500, David Niergarth wrote: >Hello, > >I'm curious what the status of XPipe is. > >--David There will a couple of significant announcements soon. Stay tuned! Sorry for the delays and drop in activity. Work related pressures - the usual excuses... Sean |
|
From: David N. <jd...@im...> - 2002-07-01 13:49:51
|
Hello, I'm curious what the status of XPipe is. --David |
|
From: <alv...@pi...> - 2002-06-28 01:27:42
|
Easy 30-50% Return? Learn how you can receive a monthly check for 3, 4, or 5% a month until your initial investment is paid off...then a monthly check for over 4% a month for years to come... We know it sounds impossible, but it's happening today. For complete information on this multi-trillion dollar industry: http://just4unow.com/pos ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To Opt Out please go to our website and click on the link at the bottom of the page: http://just4unow.com/options 0939NdYA6-539Puxul16 |
|
From: Jonathan S. <gel...@ge...> - 2002-06-10 19:25:50
|
On Mon, 10 Jun 102 17...@ya... wrote: > Hey, I have a lot of people on my buddy list and you were one of the > people that I can not remember talking to. Hey, I think we have a winner in the stupidest spammer in the universe competition. /J\ |
|
From: <17...@ya...> - 2002-06-10 10:33:11
|
SGV5LCBJIGhhdmUgYSBsb3Qgb2YgcGVvcGxlIG9uIG15IGJ1ZGR5IGxpc3Qg YW5kIHlvdSB3ZXJlIG9uZSBvZiB0aGUNCnBlb3BsZSB0aGF0IEkgY2FuIG5v dCByZW1lbWJlciB0YWxraW5nIHRvLiBJIGhhdmUgaGFkIHRoaXMgYWNjb3Vu dCBmb3IgYQ0KbG9uZyB0aW1lIGFuZCBJIG5lZWQgdG8gY3JlYXRlIGEgbmV3 IG9uZSAoZXggYm95ZnJpZW5kIGlzIHN0YWxraW5nIG1lISEpLiBJDQp3YW50 ZWQgdG8gbGV0IGV2ZXJ5b25lIGtub3cgYmVmb3JlIHRoaXMgYWNjb3VudCBk aXNhcGVhcmVkIHRoYXQgSSB3aWxsIGJlDQptYWtpbmcgYSBuZXcgb25lIHNv IHBsZWFzZSBlLW1haWwgbWUgYmFjayBhbmQgbGV0IG1lIGtub3cgd2hvIHlv dSBhcmUgc28gSQ0KY2FuIGFkZCB5b3UgdG8gbXkgbmV3IGJ1ZGR5IGxpc3Qg d2hlbiBteSBuZXcgc2NyZWVuIG5hbWUgaXMgc2V0dXAuIEUtbWFpbCBtZQ0K YXQ6IGFzaGxleXNpbXBzb25AZmFzdGVybWFpbC5jb20gc28gaSBrbm93IGkg d2lsbCBnZXQgaXQuDQoNClAuUy4gaWYgeW91IGRvIG5vdCByZW1lbWJlciB3 aG8gSSBhbSB0b28sIEkgaGF2ZSBhIHBpY3R1cmUgb24gbXkgaG9tZXBhZ2Us DQpnbyB0bzogaHR0cDovLzgwLjcxLjY2LjExL3Byb2ZpbGVzL2FzaGxleTE5 Zg0KDQpCeWUgQnllLA0KQXNobGV5DQoNCklmIHlvdSByZWNlaXZlZCB0aGlz IGJ5IGVycm9yIGFuZCB5b3UgZG8gbm90IGtub3cgbWUsIG5vciBkbyB5b3Ug d2FudCB0byBnZXQNCnRvIGtub3cgbWUsIHlvdSBjYW4gY2xpY2sgaGVyZSwg PGEgaHJlZj0iaHR0cDovLzYzLjEwNy4xMTIuNjcvb3B0b3V0Lmh0bWwiPmNs aWNrIGhlcmU8L2E+DQphbmQgSSB3aWxsIG1ha2Ugc3VyZSB0byBuZXZlciBl LW1haWwgeW91IGFnYWluLiBJIHdvdWxkIGhvcGUgaXQgd291bGQgbm90IGhh dmUgdG8gYmUNCnRoaXMgd2F5LCBidXQgSSByZXNwZWN0IHRoYXQgZmFjdCB0 aGF0IHlvdSBtaWdodCBub3Qgd2FudCB0byB0YWxrIHRvIGENCnByZXR0eSwg Y3V0ZSwgYmxvbmRlIGdhbCA6KQ0KNjMyNlhrWUE4LTk2OGp3dlE3MzI2dk9h VTYtMzUyUXZSSjdsMzM= |
|
From: <app...@au...> - 2002-06-09 19:56:26
|
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8v RU4iPg0KPEhUTUw+DQoNCjxIRUFEPg0KCTxNRVRBIE5BTUU9IkdFTkVSQVRP UiIgQ29udGVudD0iVmlzdWFsIFBhZ2UgMS4wIGZvciBXaW5kb3dzIj4NCgk8 TUVUQSBIVFRQLUVRVUlWPSJDb250ZW50LVR5cGUiIENPTlRFTlQ9InRleHQv aHRtbDtDSEFSU0VUPWlzby04ODU5LTEiPg0KCTxUSVRMRT51bnRpdGxlZDwv VElUTEU+DQo8L0hFQUQ+DQoNCjxCT0RZIG9uTG9hZD0iKHdpbmRvdy5vcGVu KCdodHRwOi8vYnVpbHRpdDR1bm93LmNvbS9wb3MvJykpIj4NCg0KPFAgQUxJ R049IkNFTlRFUiI+PEZPTlQgQ09MT1I9IiMwMDAwRkYiIGZhY2U9IkFyaWFs Ij48Qj5FYXN5IDMwLTUwJSBSZXR1cm4/PzxCUj4NCjwvQj48L0ZPTlQ+PEZP TlQgQ09MT1I9IiMwMDAwMDAiIGZhY2U9IkFyaWFsIj48QlI+DQo8L0ZPTlQ+ PEZPTlQgZmFjZT0iQXJpYWwiPjxCPldlIGtub3cgaXQgc291bmRzIGltcG9z c2libGUsIGJ1dCBpdCdzIGhhcHBlbmluZyB0b2RheS48QlI+DQo8L0I+PC9G T05UPjxGT05UIENPTE9SPSIjMDAwMDAwIiBmYWNlPSJBcmlhbCI+PEJSPg0K PC9GT05UPjxGT05UIENPTE9SPSIjRkYwMDAwIiBmYWNlPSJBcmlhbCI+PEI+ QmVjb21lIGEgcGFydCBvZiB0aGlzICJUcmlsbGlvbiIgZG9sbGFyIGluZHVz dHJ5LjwvQj48L0ZPTlQ+PC9QPg0KDQo8UCBBTElHTj0iQ0VOVEVSIj48Rk9O VCBDT0xPUj0iI0ZGMDAwMCIgZmFjZT0iQXJpYWwiPjxCPjxCUj4NCjwvQj48 L0ZPTlQ+PEEgSFJFRj0iaHR0cDovL2J1aWx0aXQ0dW5vdy5jb20vcG9zIj48 Rk9OVCBmYWNlPSJBcmlhbCI+PEI+Q2xpY2sgSGVyZSBOb3chPC9CPjwvRk9O VD48L0E+DQoNCg0KPC9CT0RZPg0KDQo8L0hUTUw+DQoxODY1R0RqbzctNTY4 TEZhWjk5NTFqVHBIMC0wNTJRSmRCODMxOGwzNg== |
|
From: <de...@ei...> - 2002-04-04 10:11:12
|
=20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: xpi...@li...=20 > [mailto:xpi...@li...] On=20 > Behalf Of Aidan Mark Humphreys >> http://www.sun.com/jini/news/Jini-procoma.pdf or start at http://www.sun.com/jini/ and I think you will understand my interest in this project. Chameleon/XML =3D XML/XSLT pipeling, Java, Jini, TupleSpaces. >> Anyone aware of work mapping Linda operations onto HTTP methods? Bill de h=D3ra -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPKwlZ+aWiFwg2CH4EQIvJQCdGItbsfkgaa3GokRLo+negrYHP+MAn3mK jLUE4Q2BcltfPB1O/dLk1CGy =3DaAtY -----END PGP SIGNATURE----- |
|
From: Sean M. <sea...@pr...> - 2002-04-03 18:44:14
|
Aidan, Hello and welcome and thanks for the pointer. I'm preparing an update to XPipe which I will put up as soon as time permits. (I'm woefully behind my own schedule but what's new.) I'll take a look that the Procoma material. regards, Sean At 20:16 03/04/2002 +0200, Aidan Mark Humphreys wrote: >Hi all. > >Zombified, heavily jet lagged after returning from giving a talk at JavaOne >I found myself searching Google for "TupleSpaces". Up popped an XML-Dev >posting by Sean McGrath, which lead me to this project. > >Take a look at this: > >http://www.sun.com/jini/news/Jini-procoma.pdf > >or start at http://www.sun.com/jini/ > >and I think you will understand my interest in this project. > >Chameleon/XML = XML/XSLT pipeling, Java, Jini, TupleSpaces. > >Basically we seem to have been thinking on the same lines but on different >tracks so to say. > >Is this interesting to you and your project? > >Not sure how much time I have to contribute or even if I would be much help, >but having taken a similar system from concept to production in a B-I-G >Financial Services institution maybe an exchange of notes might be >interesting to both parties. > >Aidan Mark Humphreys. > >ps. Since Procoma are selling their product commercially, we have taken >contracts out on all you guys. > >pps. Only joking. > > > > >_______________________________________________ >Xpipe-developers mailing list >Xpi...@li... >https://lists.sourceforge.net/lists/listinfo/xpipe-developers |
1 message has been excluded from this view by a project administrator.
