kl_account wrote:

>Hi,
> i try to implement an XML protocol (SOAP like)
> using asynchronous I/O (using java.nio.Buffer).
>
interesting project!

> I've a little problem because, i receive a
> buffer (a fragment of the document) and i
> want to parse it.
> If i use next() method, i received an exception
> at the end of the buffer.
>
i would call it *big* problem :-)

> I've two solutions to workaround, first, catch the
> exception, poor performance, second solution, use
> a wait/notify mecanism, but must create a thread, etc...
> not an asynchronous solution anymore.
>
> I think that add a method hasNext() could resolve
> my problem.
>
i think that pull parser may not be the solution to your requirements but
implementing it lower level with tokenizer driven by state machine. let
me explain:
adding async to API would require complete change in API and user would be
supposed to call hasNext() before calling getting event content right?
if hasNext() returned false then what user is supposed to do - call
next() again?
that would result in writing very cumbersome applications even when
they do not care about
asynchronous input ...

still that could be be solved with nextAsync() method that could return
special event
INCOMPLETE_READ meaning that user should try again later when input is
available
and have next() implemented so it stay backward compatible ex:
{ while(nexAsync() == INCOMPLETE_READ) ; return getEventType(); }

however bigger problem is how to implement nextAsync(). this method must
deal
with situations where return INCOMPLETE_READ is requested in every place
where next character is read from input even when you are deeply inside
parser logic
reading for example attribute value ...

something more along of state machine would work better so
parsing/tokenizing
could be stopped and resumed at any place by remembering preserving
parser state,
for some ideas how this can be done look for example on SXT (Simple XML
Tokenizer):


http://www.extreme.indiana.edu/xgws/xsoap/rmi/download/soaprmi11/src/java/sxt/

that is written as state machine and driven by one huge switch/case
statement
(you would need to add more states to record all possible positions
where more()
is called to read next input character).


let me know if you get this done - it certainly would be useful to see
what kinds of
performance and scalability gains you can get by using java.nio.

thanks,

alek

--

"Mr. Pauli, we in the audience are all agreed that your theory is crazy.
What divides us is whether it is crazy enough to be true." Niels H. D. Bohr