- From: Alex Muir <alex.g.muir@gmail.com>
- Date: Tue, 15 Mar 2011 11:02:30 +0000
- To: Alam Sher <alam.sher@advoss.com>
- Cc: Conal Tuohy <conal.tuohy@versi.edu.au>, xproc-dev@w3.org
- Message-ID: <AANLkTi=u3x9wGz=xm8_G2GM=2iK9DchF6VkVqwYUTuvP@mail.gmail.com>
"There is no persistence context in XProc either, consider a scenario where I could serialize the state of a pipeline and invoke it after a long running task would have finished, may be raise an event and a pipeline step could have been registered to listen to a special ‘Event (Event ID)’ port for later invocation?" -- Bunch of question comes to mind if anyone has some time... A. What are the priorities of XProc? B. Given a company that sucks in a lot of data, standardizes it in XML, manipulates it in various departments, and spits it as a product on various outputs. What should the following list look like if adjusted to be accurate? 1. Communication 2. Streaming -- or perhaps better to say fast and efficient 3. Extensibility 4. Bunch of easier to implement stuff? C. Would a data storage-in-memory-communication system (SIMC) which sends messages, to whatever is listening, that a new file of some id/class has been put/get data and queried as to what data is available with the option of saving files not used much to a solid state disk/db be useful tool for xproc? D. Would an XProc designed to be used solely with a SIMC simplify the language, why or why not? E. Would communication be greatly simplified as you could store any data or message on this SIMC and easily access it asynchronously? F. What is the most simple way to handle the most complex Xproc? Regards Alex
Received on Tuesday, 15 March 2011 11:10:17 UTC