BiCEP - New pages [en]

Tools

2013-01-21T22:50:32Z

Marcelo:

== FINCoS ==
The FINCoS framework is a Java-based set of benchmarking tools for load generation and performance measuring of event processing systems. It provides a flexible and neutral approach for experimenting diverse CEP systems, where load generators, datasets, queries, and adapters can be easily attached, swapped, reconfigured and scaled.

FINCoS is benchmark-independent, so it can be used both as a component in a benchmark kit and also to carry out individual performance studies.
The latest stable release (version 2.4.2, from March 2013) can be [http://fincos.googlecode.com/files/FINCoS%202.4.2.zip downloaded] from the project web [http://fincos.googlecode.com/ site].

== ''Pairs'' Benchmark kit ==
The ''Pairs'' benchmark kit is composed by four main applications:
* '''Data Generator''': generates the benchmark simulated market data.
* '''Query Generator''': produces the strategies that compose the benchmark workload.
* '''Translator''': converts the workload, initially represented in a neutral format, into the query language used by the system under test (SUT). Note that translators are vendor-specific. Currently the kit contains a sample translator for the open-source CEP engine Esper.
* '''Validator''': verifies the correctness of the answers produced by the SUT after a benchmark run.

[http://bicep.dei.uc.pt/images/5/51/Pairs_Tools_%28beta%29.zip Download ''Pairs'' Tools (''currently in beta phase'')]

In addition to the tools above, ''Pairs'' also require a benchmark driver to submit and receive events from the system under test. We recommend using the FINCoS framework to perform this function. A sample test setup file is available [http://bicep.dei.uc.pt/images/c/ca/Pairs_setup_files.zip here].

Benchmarks

2013-01-21T21:42:05Z

Marcelo: /* Pairs */

== ''Pairs'' ==
The scenario for ''Pairs'' is an investment firm where a number of analysts interact with an enterprise trading system responsible for automating and optimizing the execution of orders in stock markets. Users of the system pose trading strategies which are continuously matched against live stock market data. The task of an event processing system implementing ''Pairs'' is thus to process this tick stream and compute, for each running strategy, a set of indicators, signalizing whenever those reveal an opportunity to capitalize on market inefficiencies.

''Pairs'' was designed to assess the ability of CEP systems in processing increasingly larger number of continuous queries and event arrival rates while providing quick answers – three quality attributes equally important for an event processing engine. For that, the benchmark exercises a wide range of features commonly found in most event processing applications, including:
* Filtering, aggregation, and correlation of events;
* Detection of event patterns and trends;
* State maintenance;
* Large number of simultaneous queries (increasing with the system scale);
* Changing load conditions.

The benchmark should be implemented as illustrated in the figure below:

[[File:Benchmark Flow.png]]

Initially, the user specifies a couple of workload parameters or, alternatively, uses the standard benchmark configuration to create a test setup (1). Then, a data generator application generates data and auxiliary files (2), which are used afterwards by a query generator to produce the strategies that compose the benchmark workload (3). The output of the query generator is then parsed by a vendor-specific translator, which converts the workload, initially represented in a neutral format (e.g., xml file), into the query language used by the SUT (4). After loading the query/rule set into the SUT (5), the user starts a performance run (6). During the run, the benchmark driver (FINCoS) loads the generated data file and submits the events on it to the SUT (7), which in turn returns the corresponding results to the framework (8). After test completion, a validator verifies the correctness of the answers produced by the SUT (9).

All the aforementioned tools are written in Java and are available for download in the [http://bicep.dei.uc.pt/index.php/Tools Tools] section. Further details about the ''Pairs'' benchmark can be found on its [http://bicep.dei.uc.pt/images/8/8f/Pairs_Benchmark_%28rev._1.0%29.pdf specification] (currently on revision 1.0).

Publications

2013-01-21T19:01:29Z

Marcelo: /* Demos */

In this page you can find a list of publications produced in the ambit of the BiCEP project.
== Conferences and Journals ==
*'''Towards a Standard Event Processing Benchmark'''. Marcelo R. N. Mendes, Pedro Bizarro, and Paulo Marques. In the 4th ACM/SPEC International Conference on Performance Engineering (ICPE 2013). April, 2013 - Prague, Czech Republic.

*'''Overcoming Memory Limitations in High-Throughput Event-Based Applications'''. Marcelo R. N. Mendes, Pedro Bizarro, and Paulo Marques. In the 4th ACM/SPEC International Conference on Performance Engineering (ICPE 2013). April, 2013 - Prague, Czech Republic.

*'''Assessing and Optimizing Microarchitectural Performance of Event Processing Systems'''. Marcelo R. N. Mendes, Pedro Bizarro, and Paulo Marques. In the Second TPC Technology Conference on Performance Evaluation & Benchmarking (TPC TC). Collocated with VLDB10, September 17, 2010 - Singapore.

*'''9ticks – The Web as a Stream''' ([[Media:9ticks_dait2009.pdf‎|pdf]]). Rafael Marmelo, Pedro Bizarro, and Paulo Marques. In the First International Workshop on Database Architectures for the Internet of Things (DAIT 2009). Extended version ([[Media:9ticks_iete2009.pdf|pdf]]) also published on the 2009 September/October issue of IETE Technical Review journal.
*'''An Integrated Data Management Approach to Manage Health Care Data''' ([[Media:ICU_debs2009.pdf|pdf]]) Diogo Guerra, Dieter Gawlick, and Pedro Bizarro. In Proceedings of the 3rd ACM Intl. Conf. on Distributed Event-Based Systems (DEBS 2009).

*'''A Performance Study of Event Processing Systems''' ([[Media:Mendes_tpctc2009.pdf|pdf]]). Marcelo R. N. Mendes, Pedro Bizarro, and Paulo Marques. In the First TPC Technology Conference on Performance Evaluation & Benchmarking (TPC TC). Collocated with VLDB09, August 24, 2009 - Lyon France.

*'''BiCEP - Benchmarking Complex Event Processing Systems''' ([http://drops.dagstuhl.de/opus/volltexte/2007/1143/pdf/07191.BizarroPedro.ExtAbstract.1143.pdf pdf]). Pedro Bizarro in [http://www.dagstuhl.de Dagshtul] Event Processing Seminar, 2007. (POSITION PAPER)

== Demos ==
*'''FINCoS: Benchmark Tools for Event Processing Systems'''. Marcelo R. N. Mendes, Pedro Bizarro, and Paulo Marques. In the 4th ACM/SPEC International Conference on Performance Engineering (ICPE 2013). April, 2013 - Prague, Czech Republic.

*'''Flood: elastic streaming MapReduce'''. David Alves, Pedro Bizarro, and Paulo Marques. In Proceedings of the 4th ACM Intl. Conf. on Distributed Event-Based Systems (DEBS 2010), 113-114.

*'''A framework for performance evaluation of complex event processing systems''' ([[Media:FINCoS_DEBS2008.pdf|pdf]]). Marcelo R. N. Mendes, Pedro Bizarro, and Paulo Marques. In Proceedings of the 2nd ACM Intl. Conf. on Distributed Event-Based Systems (DEBS 2008), 313-316.

== Tutorials ==
*'''Benchmarking Event Processing Systems: Current State and Future Directions''' Marcelo R. N. Mendes, Pedro Bizarro, Paulo Marques In the First Joint WOSP/SIPEW International Conference on Performance Engineering, San Jose, California, USA, January 28, 2010.
([[Media:BiCEP_wosp2010.pdf|pdf]])

9ticks:Unsorted List of Requirement

2008-10-08T22:13:28Z

Rafael:

{| class="TablePager sortable" border="1" width="100%"
|-
! Code !! width="50%" | Requirement !! width="40%" | Comment !! Priority !! Status
|-
| REQ_0001 || User shall access the system through a web browser. || || 1 || Draft
|-
| REQ_0002 || User shall access the system through a mobile device. || || 1 || Draft
|-
| REQ_0003 || User shall subscribe sources. || || 1 || Draft
|-
| REQ_0004 || User shall tag sources. || || 1 || Draft
|-
| REQ_0005 || User shall visualize each source from several perspectives. || e.g.: textual, bar chart, pie chart, ... || 1 || Draft
|-
| REQ_0006 || User shall visualize sources in comparison mode. || e.g.: overlap two stock quotes || 1 || Draft
|-
| REQ_0007 || User shall define when and how be alerted of events. || || 1 || Draft
|-
| REQ_0008 || User shall visualize the history of any source. || || 1 || Draft
|-
| REQ_0009 || User shall perform queries over the gathered data. || || 1 || Draft
|-
| REQ_0010 || Queries, visualizations and filters shall be stored for future re-utilization by any user. || || 1 || Draft
|-
| REQ_0011 || User shall perform all operations in real-time. || Minimum delays. || 1 || Draft
|-
| REQ_0101 || There shall exist a data source API. Details are TBD. || Every source, predefined or custom, must use this API. || 1 || Draft
|-
| REQ_0102 || User shall apply queries or filters to data sources. The result shall be considered as another source, widely available. || || 1 || Draft
|-
| REQ_0201 || A predefined Stock source shall be able to be subscribed. || Market and quote must be provided. || 1 || Draft
|-
| REQ_0202 || A predefined Weather source shall be able to be subscribed. || Location must be provided (defaulting to the IP physical location). || 1 || Draft
|-
| REQ_0203 || A predefined Sports source shall be able to be subscribed. || A specific match (source is only that match) or generic team (all team matches) must be provided. || 1 || Draft
|-
| REQ_0204 || A predefined Flight source shall be able to be subscribed. || Flight number and flight date must be provided. || 1 || Draft
|-
| REQ_0205 || A predefined Traffic source shall be able to be subscribed. || Route must be provided. || 1 || Draft
|-
| REQ_0206 || A predefined RSS Feed source shall be able to be subscribed. || RSS URL must be provided. || 1 || Draft
|-
| REQ_0207 || A predefined eBay item source shall be able to be subscribed. || Item ID must be provided. || 1 || Draft
|-
| REQ_0301 || User shall use a browser extension to select some peaces of information to monitor. || || 1 || Draft
|-
| REQ_0302 || The information selected shall be automatically typed. || May be overridden by the user. || 1 || Draft
|-
| REQ_0303 || System shall recognize basic data types. || e.g.: integer, decimal, percentage, time, date, string, ... || 1 || Draft
|-
| REQ_0304 || System shall connect similar/equivalent data types. || e.g.: Celsius, Fahrenheit, Kelvin, ... ; Meter, Mile, Yard, Foot, ... ; Euro, U.S. Dollar, Pound, Swiss franc, ... || 1 || Draft
|-
| REQ_0305 || Any single HTML item shall be able to be selected. || e.g.: a table cell or an anchor. || 1 || Draft
|-
| REQ_0306 || Every repetitive HTML item shall be able to be selected. || e.g.: all main titles || 1 || Draft
|-
| REQ_0307 || An HTML table shall be able to be selected. || || 1 || Draft
|-
| REQ_0308 || Parts of an HTML table shall be able to be selected. || e.g.: a row whose cell at nth column has the value X || 1 || Draft
|-
| REQ_0309 || All items inside a bounded polygon shall be able to be selected. || || 1 || Draft
|-
| REQ_0310 || Each custom source shall be stored for future re-utilization by any user. || || 1 || Draft
|-
| REQ_0401 || Each user's alert rules shall be processed on-the-fly. || Use a CEP engine, Esper maybe. || 1 || Draft
|-
| REQ_0402 || User shall be alerted in a short time window. || || 1 || Draft
|-
| REQ_0501 || Each source must be polled for updates every "refresh rate"-times. || Based on each source's refresh rate. || 1 || Draft
|-
| REQ_0502 || An efficient scheduling policy shall be in place. || || 1 || Draft
|-
| REQ_0503 || The solution shall have good performance and scalability. || || 1 || Draft
|-
| REQ_0504 || The solution shall handle stress peaks. || Many sources, many events and many users || 1 || Draft
|-
| REQ_0601 || An aggregation engine shall be in place. || Summarize older data. || 1 || Draft
|-
| REQ_0602 || A fault tolerant mechanism must be in place. || Replicate data. || 1 || Draft
|-
| REQ_0603 || A fault tolerant mechanism must be in place. || Replicate data. || 1 || Draft
|-
| REQ_0604 || A locking service must be in place. || Low level concurrency prevention. || 1 || Draft
|-
| REQ_0605 || The solution shall have good performance and scalability. || || 1 || Draft
|-
| REQ_0606 || The solution shall handle stress peaks. || Many Sources, Many Events and Many users || 1 || Draft
|-
| REQ_0607 || The solution shall provide low response times. || || 1 || Draft
|-
| REQ_0701 || The communication between the user and the system must be optimize in order of each client type. || Push-based vs pull-based. || 1 || Draft
|-
| REQ_0702 || The system shall provide a web service for third-party applications. || || 1 || Draft
|-
| REQ_0703 || The system shall be internationalized. || i18n || 5 || Draft
|-
| REQ_0704 || The system shall allow OpenID authentication. || || 5 || Draft
|}

9ticks:Software Requirements Specification

2008-10-08T13:24:19Z

Rafael:

== Requirements Overview ==

* Retrieve, interpret and store data source events
* Web and mobile-based frontends
* Predefined and custom data sources
* Visualizations
* Queries
* Alerts
* History
* Tags

== List of Requirements ==

* The distinction between user, functional and non-functional requirements is ignored
* The requirements are sorted by logical groups
* Each requirement has been assigned with the following properties:
** '''Code''' — REQ_[0-9]{4}
** '''Requirement'''
** '''Comment'''
** '''Priority''' — from 1 to 5 (1 as highest)
** '''Status''' — Draft, Approved, In Progress, Testing, Finished
* To see an '''unsorted list of requirement''' folow '''[[9ticks:Unsorted_List_of_Requirement|this]]''' link.

=== Generic ===

{| class="TablePager" border="1" width="100%"
|-
! Code !! width="50%" | Requirement !! width="40%" | Comment !! Priority !! Status
|-
| REQ_0001 || User shall access the system through a web browser. || || 1 || Draft
|-
| REQ_0002 || User shall access the system through a mobile device. || || 1 || Draft
|-
| REQ_0003 || User shall subscribe sources. || || 1 || Draft
|-
| REQ_0004 || User shall tag sources. || || 1 || Draft
|-
| REQ_0005 || User shall visualize each source from several perspectives. || e.g.: textual, bar chart, pie chart, ... || 1 || Draft
|-
| REQ_0006 || User shall visualize sources in comparison mode. || e.g.: overlap two stock quotes || 1 || Draft
|-
| REQ_0007 || User shall define when and how be alerted of events. || || 1 || Draft
|-
| REQ_0008 || User shall visualize the history of any source. || || 1 || Draft
|-
| REQ_0009 || User shall perform queries over the gathered data. || || 1 || Draft
|-
| REQ_0010 || Queries, visualizations and filters shall be stored for future re-utilization by any user. || || 1 || Draft
|-
| REQ_0011 || User shall perform all operations in real-time. || Minimum delays. || 1 || Draft
|}

=== Sources ===

{| class="TablePager" border="1" width="100%"
|-
! Code !! width="50%" | Requirement !! width="40%" | Comment !! Priority !! align="center" | Status
|-
| REQ_0101 || There shall exist a data source API. Details are TBD. || Every source, predefined or custom, must use this API. || 1 || Draft
|-
| REQ_0102 || User shall apply queries or filters to data sources. The result shall be considered as another source, widely available. || || 1 || Draft
|}

=== Predefined Sources ===

{| class="TablePager" border="1" width="100%"
|-
! Code !! width="50%" | Requirement !! width="40%" | Comment !! Priority !! align="center" | Status
|-
| REQ_0201 || A predefined Stock source shall be able to be subscribed. || Market and quote must be provided. || 1 || Draft
|-
| REQ_0202 || A predefined Weather source shall be able to be subscribed. || Location must be provided (defaulting to the IP physical location). || 1 || Draft
|-
| REQ_0203 || A predefined Sports source shall be able to be subscribed. || A specific match (source is only that match) or generic team (all team matches) must be provided. || 1 || Draft
|-
| REQ_0204 || A predefined Flight source shall be able to be subscribed. || Flight number and flight date must be provided. || 1 || Draft
|-
| REQ_0205 || A predefined Traffic source shall be able to be subscribed. || Route must be provided. || 1 || Draft
|-
| REQ_0206 || A predefined RSS Feed source shall be able to be subscribed. || RSS URL must be provided. || 1 || Draft
|-
| REQ_0207 || A predefined eBay item source shall be able to be subscribed. || Item ID must be provided. || 1 || Draft
|}

=== Custom Sources ===

{| class="TablePager" border="1" width="100%"
|-
! Code !! width="50%" | Requirement !! width="40%" | Comment !! Priority !! Status
|-
| REQ_0301 || User shall use a browser extension to select some peaces of information to monitor. || || 1 || Draft
|-
| REQ_0302 || The information selected shall be automatically typed. || May be overridden by the user. || 1 || Draft
|-
| REQ_0303 || System shall recognize basic data types. || e.g.: integer, decimal, percentage, time, date, string, ... || 1 || Draft
|-
| REQ_0304 || System shall connect similar/equivalent data types. || e.g.: Celsius, Fahrenheit, Kelvin, ... ; Meter, Mile, Yard, Foot, ... ; Euro, U.S. Dollar, Pound, Swiss franc, ... || 1 || Draft
|-
| REQ_0305 || Any single HTML item shall be able to be selected. || e.g.: a table cell or an anchor. || 1 || Draft
|-
| REQ_0306 || Every repetitive HTML item shall be able to be selected. || e.g.: all main titles || 1 || Draft
|-
| REQ_0307 || An HTML table shall be able to be selected. || || 1 || Draft
|-
| REQ_0308 || Parts of an HTML table shall be able to be selected. || e.g.: a row whose cell at nth column has the value X || 1 || Draft
|-
| REQ_0309 || All items inside a bounded polygon shall be able to be selected. || || 1 || Draft
|-
| REQ_0310 || Each custom source shall be stored for future re-utilization by any user. || || 1 || Draft
|}

=== Event Processing ===

{| class="TablePager" border="1" width="100%"
|-
! Code !! width="50%" | Requirement !! width="40%" | Comment !! Priority !! Status
|-
| REQ_0401 || Each user's alert rules shall be processed on-the-fly. || Use a CEP engine, Esper maybe. || 1 || Draft
|-
| REQ_0402 || User shall be alerted in a short time window. || || 1 || Draft
|}

=== Crawler ===

{| class="TablePager" border="1" width="100%"
|-
! Code !! width="50%" | Requirement !! width="40%" | Comment !! Priority !! Status
|-
| REQ_0501 || Each source must be polled for updates every "refresh rate"-times. || Based on each source's refresh rate. || 1 || Draft
|-
| REQ_0502 || An efficient scheduling policy shall be in place. || || 1 || Draft
|-
| REQ_0503 || The solution shall have good performance and scalability. || || 1 || Draft
|-
| REQ_0504 || The solution shall handle stress peaks. || 1000 Streams, 1000 Events/sec, 1000 Queries || 1 || Draft
|}

=== Data Store ===

{| class="TablePager" border="1" width="100%"
|-
! Code !! width="50%" | Requirement !! width="40%" | Comment !! Priority !! Status
|-
| REQ_0601 || An aggregation engine shall be in place. || Summarize older data. || 1 || Draft
|-
| REQ_0602 || A fault tolerant mechanism must be in place. || Replicate data. || 1 || Draft
|-
| REQ_0603 || A fault tolerant mechanism must be in place. || Replicate data. || 1 || Draft
|-
| REQ_0604 || A locking service must be in place. || Low level concurrency prevention. || 1 || Draft
|-
| REQ_0605 || The solution shall have good performance and scalability. || || 1 || Draft
|-
| REQ_0606 || The solution shall handle stress peaks. || 1000 Streams, 1000 Events/sec, 1000 Queries || 1 || Draft
|-
| REQ_0607 || The solution shall provide low response times. || || 1 || Draft
|}

=== Assorted ===

{| class="TablePager" border="1" width="100%"
|-
! Code !! width="50%" | Requirement !! width="40%" | Comment !! Priority !! Status
|-
| REQ_0701 || The communication between the user and the system must be optimize in order of each client type. || Push-based vs pull-based. || 1 || Draft
|-
| REQ_0702 || The system shall provide a web service for third-party applications. || || 1 || Draft
|-
| REQ_0703 || The system shall be internationalized. || i18n || 5 || Draft
|-
| REQ_0704 || The system shall allow OpenID authentication. || || 5 || Draft
|}

== Requirement Traceability Matrix ==

Not needed, yet.

9ticks:Software Architecture

2008-10-07T16:55:20Z

Rafael: Removing all content from page

9ticks:2008.10.09

2008-10-02T15:54:05Z

Rafael:

* Plan
* Architecture Design
* [http://esper.codehaus.org/ Esper]

9ticks:2008.10.02

2008-10-02T15:24:13Z

Rafael:

=== Major Components ===

* User Interface
* Crawler
* Data Store
* Predefined Sources
* Custom Source UI
* '''?'''

=== Crawler ===

* Scheduling Policy
* Distributed crawl

=== Data Store ===

* BigTable + GFS
* Hadoop + HBase
* Map-Reduce
* RRDtool

=== Data Store Bigtable-like ===

{| class="TablePager" border="1"
|-
! Row Key
! Timestamp
! Column "property:trade"
! Column "property:volume"
! Column "property:temperature"
! Column "property:humidity"
|-
| stock.AAPL
| t1
| 109.12
| 200
|
|
|-
|
| t2
| 109.10
|
|
|
|-
|
| t3
| 109.05
| 200
|
|
|-
| weather.Coimbra
| t7
|
|
| 13
| 87
|-
|
| t8
|
|
| 14
| 78
|}

{| class="TablePager" border="1"
|-
! Row Key
! Timestamp
! Column "property:trade"
! Column "property:volume"
|-
| stock.AAPL
| t1
| 109.12
| 200
|-
|
| t3
| 109.05
| 200
|}

{| class="TablePager" border="1"
|-
! Row Key
! Timestamp
! Column "property:trade"
|-
| stock.AAPL
| t2
| 109.10
|}

{| class="TablePager" border="1"
|-
! Row Key
! Timestamp
! Column "property:temperature"
! Column "property:humidity"
|-
| weather.Coimbra
| t7
| 13
| 87
|-
|
| t8
| 14
| 78
|}

9ticks:Overview

2008-10-02T15:13:01Z

Rafael:

== Overview ==

* Retrieve, interpret and store data source events
* Predefined and custom data sources
* Visualizations
* Queries
* Alerts
* Tags
* Web and mobile-based frontends
* History

== State of the Art ==

=== Alerts.com ===

The information you want when and where you want it. You're in control. Weather, news, traffic, gas prices, reminders, live sports and more. It's new, it's free, your personal information is secure, no spam. [http://www.alerts.com/ www.alerts.com]

=== Chartlet ===

Chartlet is a free Firefox extension that periodically checks places on the Web, extract and stores numerical values. On demand, you can display the history of those values in nice charts. [http://www.chartlet.net/ www.chartlet.net]

=== WebSundew ===

WebSundew is an advanced web scraping tool that extracts data from web pages on the internet: 100% graphic user interface, step-by-step template wizards, automatic iteration for linked pages, macros for automatic log into sites and data extraction. [http://www.websundew.com/ www.websundew.com]

=== RRDtool ===

RRDtool is the OpenSource industry standard, high performance data logging and graphing system for time series data. Use it to write your custom monitoring shell scripts or create whole applications using its Perl, Python, Ruby, TCL or PHP bindings. [http://oss.oetiker.ch/rrdtool/ oss.oetiker.ch/rrdtool]

== Data Sources ==

=== Predefined ===

* TBD Sources: stocks, flight schedules, weather, sports, auctions, traffic reports, feeds, sensors, ...
* Makes use of data source API
* May make use of external APIs

=== Custom ===

* TBD Sources: html table, html items, ...
* Makes use of data source API
* User may identify items to monitor in the following ways:
** '''Single Page Entry''' -- single page items
** '''Same Level Page Entries''' -- every news title, repetitive patterns
** '''Table Selection''' -- smartly select all table items
** '''Table Line Selection by Constant Column Value''' -- select something in the same row/column whose column/row has something wrote on it
** '''Automatic Selection Inside Area''' -- smartly select every item inside a bounded polygon or even the whole page
** '''Advanced Text Selection''' -- left of something and/or right of something, bounded by something
* Browser extension is an option
* Each item data type must be automatically chosen by the system. May be overridden by the user.

== Data Source API ==

* Modular approach
* Every DS adapter will make use of this API
* Each item has the following properties:
** '''Name''' -- identification
** '''XPath''' -- location in the page
** '''Type''' -- data type (following section)

== Data Types ==

* Suggest the best type for each item
* TBD Data types:
** Integer
** Decimal
** Percentage
** Value -- temp, speed, height, weight, ...
** Time
** Date
** DateTime -- event timestamp
** String
* Connect similar/equivalent data types:
** Celsius, Fahrenheit, Kelvin, ...
** Metre, Mile, Yard, Foot, ...
** Euro, U.S. Dollar, Pound, Swiss franc, ...

== Data Interpretation ==

* Show data from several angles TBD
* Mix/Join data sources

== Data Store ==

* Performance
* Scalability
* Use RRDtool or a similar approach
** Round Robin Database
** Bounded storage footprint
** Sampling
** Custom levels of aggregation
* Client-side history
* Queries, visualisations and filters may be stored for future re-utilization by any user
* '''Distributed memory (condor-like)'''

== User Interface ==

* Web-based
* Mobile
* TBD Push/Pull-based

== Miscellaneous ==

* OpenID login
* i18n

== Firefox Extension ==

[http://student.dei.uc.pt/~rjmm/firefox/9ticks.xpi 9ticks Firefox extension]

=== Use cases ===

* [http://eztv.it/index.php?main=airs Series Countdown List]
* [http://dsg.dei.uc.pt/ganglia/ DSG Cluster]
* [http://www.maisfutebol.iol.pt/superliga_classificacao.php Liga Sagres]
* [http://news.bbc.co.uk/sport2/hi/football/eng_prem/table/default.stm Barclays Premier League]
* [http://weather.no.sapo.pt/details.html Manteigas Weather]
* [http://www.osnews.com/ OSNews]
* [http://finance.google.com/finance?q=NASDAQ:AAPL Apple Google Finance]
* [http://www.timeanddate.com/counters/newyear.html New Year Countdown]
* [http://www.traffic.com/New-York-Traffic/I-278_Gowanus_Expressway___Brooklyn_Queens_Exwy-NORTHBOUND-7_NB_GW_BQE_12.html NY I-278 Traffic]
* [http://www.ebay.com/ Ebay]

9ticks

2008-10-02T15:12:41Z

Rafael:

''"Events for the Masses"''

=== Documents ===

[[9ticks:Software_Requirements|Software Requirements]]

[[9ticks:Software_Architecture|Software Architecture]]

=== Progress Reports ===

[[9ticks:Older|Older]]

[[9ticks:2008.10.02|2008.10.02]]

[[9ticks:2008.10.09|2008.10.09]]