Return-Path: 
 <cocoon-users-return-17680-apmail-xml-cocoon-users-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org
Received: (qmail 76266 invoked by uid 500); 30 Mar 2001 14:07:57 -0000
Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-users-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-users-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-users@xml.apache.org>
Reply-To: cocoon-users@xml.apache.org
Delivered-To: mailing list cocoon-users@xml.apache.org
Received: (qmail 76227 invoked from network); 30 Mar 2001 14:07:54 -0000
Date: Sat, 31 Mar 2001 01:02:29 +1000
From: Jeff Turner <jeff@socialchange.net.au>
To: cocoon-users@xml.apache.org
Subject: Web services and Cocoon (was: Re: Central repository for taglibs)
Message-ID: <20010331010225.A1065@socialchange.net.au>
Mail-Followup-To: cocoon-users@xml.apache.org
References: <20010328083723.B5705@socialchange.net.au>
 <Pine.GSO.4.10.10103280042560.13236-100000@denics7.denic.de>
 <20010328164001.I8067@socialchange.net.au> <3AC19C41.3F1EAC2@denic.de>
 <20010328223927.A1071@socialchange.net.au> <3AC1DBE9.75DD6198@denic.de>
 <20010329121532.C21438@socialchange.net.au> <3AC3014E.39748262@denic.de>
 <20010329231641.F1069@socialchange.net.au> <3AC336AB.FECF9923@denic.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <3AC336AB.FECF9923@denic.de>;
 from ulim@denic.de on Thu, Mar 29, 2001 at 03:20:43PM +0200
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

On Thu, Mar 29, 2001 at 03:20:43PM +0200, Ulrich Mayring wrote:
> Jeff Turner wrote:
> > 
> > I've seen this demo, and it's extremely cool. I doubt if anyone else is
> > pushing web-based, open source xsl:fo this far. This is the type of
> > showcase application that can do wonders for Cocoon PR if it was more
> > widely publicized.
> 
> The best is yet to come. The next generation of the DocHandler will
> provide a way to call Cocoon via SOAP, thus getting rid of the
> ProducerFromRequest-paradigm. The PDF archive index will be moved from
> files to a database. These two features already work, but haven't been
> put into production yet. If Ron ever finds the time to give me my own
> mysql login and db tables, I'll be able to upgrade the live samples :)

Cool.. it sounds like you're aiming at full-on "web services", SOAP,
UDDI, WSDL etc.

IBM is very active in this area. A few days ago, they came out with a
"TSpaces Development Kit":

 ".. to assist the creation, discovery, and integration of Web services.
 [..]  Development tools provided in the first version of the package
 include .. Universal printing solution: a sample printing service that
 enables printing from any computer to any printer, regardless of the
 host computers (workstations, PCs, handheld devices), operating
 systems, or file format."

   -- http://xml.coverpages.org/ni2001-03-27-a.html

"Universal printing solution" sounds what you're aiming at.

Wonder how C2 could do as a generic SOAP server, into which SOAP
services could be plugged.

> Also, while it may sound a bit dry, the first feature is very important,
> because it allows me to use Cocoon to generate the PDFs dynamically.
> Now, you might think this is not very hard, just open an URLConnection
> and see what Cocoon gives you. But what if you want to supply parameters
> to Cocoon on how the PDF is supposed to be created? Of course you can
> use HTTP request parameters, but they are flat. So, for example, you can
> never send address data to an XML file via HTTP request parameters,
> since address data needs a more complex structure like:
> 
> <address type="person">
> <name>Mayring</name>
> <firstname>Ulrich</firstname>
> ...
> </address>
> 
> <address type="company">
> ...
> </address>

Well.. XML over HTTP works for a lot of people. You just open a socket
and POST a bunch of XML.

> This type of structure cannot be encoded in HTTP request parameters,
> unless you do things like
> address1=person&name1=Mayring&firstname1=Ulrich&address2=company&... -
> but this is hardly elegant, hell to maintain and very prone to errors.
> Not to speak of the 1024 character limit for URLs. Alternatively you can
> make one URLConnection per address, but what if I want just one PDF with
> perhaps 1000 addresses on it?
> 
> So I devised a way to actually build a rich XML structure like shown
> above and make it possible to pass this to an XML page as parameters.
> Then you can select the bits you need with XSLT and let XSLFO and fop
> make a nice PDF from it. Since this technique is not really related to
> SOAP, I should take it out of the SOAP taglib and make something more
> generic. But first I want to test this in production to see if it is
> easy and stable enough to use.

Hmm.. that sounds useful if it's a generic tool. I've often wanted to
pass structured data from a HTML form (where XML isn't an option) to a
servlet, and once invented a mini-language for this (parser written in
JPython). Berin or someone on cocoon-dev recently proposed an XForms
project, which this might tie in with.

> Next up is to make it so that I can actually print over the Internet,
> not only locally like now. I want to replace lpr with something more
> suited to bulk printing. Then perhaps upgrade the fax feature
> accordingly and implement an emailer. Then I'll open a direct marketing
> firm and draft a W3C standard on XML-based spamming :-)

Wohoo :) "<lies>Make $$$ fast!!</lies>"

--Jeff

 
> Ulrich
> 
> -- 
> Ulrich Mayring
> DENIC eG, Systementwicklung

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>