[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-oro-dev
Subject:    RE: Wanted: Regex[Input|Output]Stream
From:       "Noel J. Bergman" <noel () devtech ! com>
Date:       2003-09-20 3:07:00
[Download RAW message or body]

Daniel,

Sorry for the time gap, but I've been consumed on some other projects, and
am just getting back to this topic.  I've two issues that I need to resolve.

  (1) I have data arriving on a feed that I want to
      read and process, but I would like to check it
      against multiple expressions (see 2) in real-
      time and recognize when one has been matched.

  (2) I need to have multiple expressions, and am
      not seeing support for that in ORO or any of
      the other Java regex packages.  Processing a
      gigabyte of data for every 1 megabyte of real
      data because I have 1K expressions does not
      seem overly efficient.

If there is a ready-made solution to (2), please let me know.  Or is the
easy way to do avoid searching for:

  R1, R2, R3, ... Rn

to do:

  (R1)|(R2)|(R3)|...|(Rn)?

(yes, I realize that a limitation is that I wouldn't get to know which Rn
has matched) and what is ORO's limit?  Or do you have a better way that I'm
missing?

An example of (1) is doing real-time pattern matching in the incoming stream
of a mail server while we process the data.  Now, another way of doing it
would be for me to use push-processing (think java.nio) and push blocks of
data into the regex matcher before pushing the data into the protocol
handler.  Yes, to answer one of your other messages, I would want matching
to continue from where it left off.  If a Listener approach is used, I just
want it to fire off RegexNotificationEvent as a pattern is recognized.

The FSA should assume that there is more data to arrive until told
otherwise.  And, yes, the matcher would have to preserve the state of its
FSA.  With respect to NFA vs DFA, for all NFA there exists an equivalent
DFA, albeit with quite a few more states, but perhaps I am missing your
point.

One other stipulation.  I am assuming a long-lived recognizer with a lot of
data, so I am quite willing to expend more cycles up front to compile a
relatively optimized FSA in exchange for efficient processing during the
main duty cycle.

Does this better explain what I'm looking for, and where I'm coming from?

	--- Noel

http://camino.rutgers.edu/ut/utsa/cs1713-1/assign3/ramble.html
http://sources.redhat.com/ml/bug-glibc/2002-03/msg00295.html
http://www.cs.duke.edu/~rodger/tools/jflap/jflap99/flap/JFLAP11.html
http://www.cs.duke.edu/~rodger/tools/jflap/


---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]