Sponsored Content
Special Forums News, Links, Events and Announcements Complex Event Processing RSS News Changhai Ke of ILOG: The “More” Part of CEP over ESP is Far from Mature Post 302212083 by Linux Bot on Sunday 6th of July 2008 08:10:13 AM
Old 07-06-2008
Changhai Ke of ILOG: The “More” Part of CEP over ESP is Far from Mature

Tim Bass
Sun, 06 Jul 2008 11:58:30 +0000
This post was originally a comment*On CEP Maturity and the Gartner Hype Cycle*by Changhai Ke of ILOG.* Changhai Ke’s comment was so well written, I have reposted*it as a blog entry:
An EDA and CEP must be understood as 2 different areas. EDA is an architecture pattern for enterprise applications. The components are loosely coupled by the use of events. In its strict sense, this is more an architecture pattern than an algorithm.
CEP, on the other hand, targets at the event processing and pattern recognition level. For me, it's the research for the right algorithm to use to recognize the situations. Pattern recognition, event correlation are all good characterizations for CEP. Back 15 years ago, the alarm correlation in the telecom area was done using production rules (it is still the case), and this perfectly falls into the CEP area.
In fact, EDA comes after CEP, but the CEP at that period was not explicitly called CEP. The nature of their respective study is not the same, one is at the architecture and middleware level, the other is at the algorithm side. As both are concerned by events, it seems that people more or less implicitly include CEP in EDA, mix the two and introduce confusion. Why not. But it's important to understand that CEP (on its algorithm side) could mature on its way without being worried about the event transportation layer.
As a system, CEP needs input events for processing. If EDA is considered as the only way to bring and transport events to the CEP systems, then of course CEP won't become successful without the prior success of EDA. But in my understanding, CEP targets some real-time or close to real-time applications, and the event transport layer in those applications are the most often ad-hoc and over-optimized. I fear that EDA has the same kind of performance goal.
Another distinction needs to be made. CEP is more general than ESP (event stream processing), characterized by an EPL for data aggregation with notifications. Even on the market most of the CEP vendors provide EPL languages, CEP has the vocation to cover more than that. The “more” part is not well defined, at least it should include the event correlation, and correlation is not just data aggregation.
The ESP part of CEP could be considered as quite mature. There are so many EPL languages, and tuning has been made on the runtime side. It seems also that some applications based on ESP have proved to work. But the “more” part of CEP over ESP is far from mature. It is often described that CEP could use several technologies, such as statistical models, Bayesian network, time series, rules, etc. I agree that there are a few systems using rules. But where are the others?
Sincerely,
Changhai Ke


Source...
 
wrjpgcom(1)							   User Commands						       wrjpgcom(1)

NAME
wrjpgcom - insert text comments into a JPEG file SYNOPSIS
wrjpgcom [-replace] [-comment text] [-cfile name] [filename] DESCRIPTION
wrjpgcom reads the named JPEG or JFIF file, or the standard input if no file is named, and generates a new JPEG or JFIF file on the stan- dard output. A comment block is added to the file. The JPEG standard allows "comment" (COM) blocks to occur within a JPEG file. Although the standard does not actually define the intended function of COM blocks, they are widely used to hold user-supplied text strings. This enables you to add annotations, titles, index terms, and so on to your JPEG files, and later retrieve the COM blocks as text. COM blocks do not interfere with the image stored in the JPEG file. The maximum size of a COM block is 64K, but you can have many COM blocks in one JPEG file. wrjpgcom adds a COM block, containing text that you provide, to a JPEG file. Ordinarily, the COM block is added after any existing COM blocks, but you can delete the old COM blocks if you wish. OPTIONS
The following options are supported: -cfile name Read the text for a new COM block from the named file. -comment text Supply the text for a new COM block on the command line. -replace Delete any existing COM blocks from the file. OPERANDS
The following operands are supported: filename The name of the JPEG file to which you want to add text comments. EXTENDED DESCRIPTION
To add only one line of comment text, use the -comment option to provide the text on the command line. Specify the comment text within quotes, so that the text is treated as a single argument. Longer comments can be read from a text file. If you specify neither the -comment nor the -cfile option, wrjpgcom reads the comment text from standard input. In such cases, you must supply an input image filename. You can enter multiple lines, up to 64KB. Type an end-of-file indicator, usually Ctrl-D, to terminate the comment text entry. wrjpgcom does not add a COM block if the provided comment string is empty. Therefore, you can use -replace -comment "" to delete all COM blocks from a file. EXAMPLES
Example 1: Adding a Short Comment to in.jpg to Produce out.jpg example% wrjpgcom -c "View of my back yard" in.jpg > out.jpg Example 2: Attaching a Long Comment Previously Stored in comment.txt example% wrjpgcom in.jpg < comment.txt > out.jpg or example% wrjpgcom -cfile comment.txt < in.jpg > out.jpg In this example, 1000 is a number that is larger than the number of rows in the source file. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Availability |SUNWjpg | +-----------------------------+-----------------------------+ |Interface stability |External | +-----------------------------+-----------------------------+ SEE ALSO
cjpeg(1), djpeg(1), jpegtran(1), rdjpgcom(1) NOTES
This man page was originally written by the Independent JPEG Group. Updated by Breda McColgan, Sun Microsystems Inc., 2004. SunOS 5.10 26 Mar 2004 wrjpgcom(1)
All times are GMT -4. The time now is 08:33 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy