CrawlerArchitecture - Revision history

Martin.schneider: US 97798972, remove everything related to facebook

2015-07-07T12:50:00Z

US 97798972, remove everything related to facebook

← Older revision		Revision as of 12:50, 7 July 2015
Line 1:		Line 1:
	= Architecture of the Social OX PlugIn (crawler) bundle =		= Architecture of the Social OX PlugIn (crawler) bundle =

	Each 3rd-Party-Service ~~(e.g. Facebook)~~ is represented by a separate		Each 3rd-Party-Service is represented by a separate
	OSGI-Service-instance (type "GenericSubscribeService"). These services		OSGI-Service-instance (type "GenericSubscribeService"). These services
	each contain a description (type "CrawlerDescription") of how to access		each contain a description (type "CrawlerDescription") of how to access

Khgras at 09:20, 22 December 2010

2010-12-22T09:20:13Z

← Older revision		Revision as of 09:20, 22 December 2010
Line 1:		Line 1:
	= Architecture of the crawler bundle =		= Architecture of the Social OX PlugIn (crawler) bundle =

	Each 3rd-Party-Service (e.g. Facebook) is represented by a separate		Each 3rd-Party-Service (e.g. Facebook) is represented by a separate

Dennis Sieben: /* Architecture of the crawler bundle */

2010-03-04T10:08:04Z

Architecture of the crawler bundle

Dennis Sieben: /* Architecture of the crawler bundle */

2010-03-04T10:06:17Z

Architecture of the crawler bundle

← Older revision		Revision as of 10:06, 4 March 2010
Line 2:		Line 2:

	Each 3rd-Party-Service (e.g. Facebook) is represented by a separate		Each 3rd-Party-Service (e.g. Facebook) is represented by a separate
	OSGI-Service-instance (type ~~“GenericSubscribeService”~~). These services		OSGI-Service-instance (type ”GenericSubscribeService”). These services
	each contain a description (type “CrawlerDescription”) of how to access		each contain a description (type “CrawlerDescription”) of how to access
	“their” 3rd-Party-Service. Every time the OSGI-Bundle		“their” 3rd-Party-Service. Every time the OSGI-Bundle
	“c.o.subscribe.crawler” is started these descriptions get updated via		“com.openexchange.subscribe.crawler” is started these descriptions get updated via
	reading YML-files (one for each 3rd-Party-Service). So to update a		reading YML-files (one for each 3rd-Party-Service). So to update a
	“Crawler” a new YML-file has to be placed in the appropriate directory		“Crawler” a new YML-file has to be placed in the appropriate directory

Choeger: /* Architecture of the crawler bundle */

2009-10-08T11:26:05Z

Architecture of the crawler bundle

← Older revision		Revision as of 11:26, 8 October 2009
Line 20:		Line 20:

	[[File:Crawler_Architecture.jpg]]		[[File:Crawler_Architecture.jpg]]

			[[Category: OX6]]

Choeger: Created page with '= Architecture of the crawler bundle = Each 3rd-Party-Service (e.g. Facebook) is represented by a separate OSGI-Service-instance (type “GenericSubscribeService”). These serv...'

2009-10-07T11:34:31Z

Created page with '= Architecture of the crawler bundle = Each 3rd-Party-Service (e.g. Facebook) is represented by a separate OSGI-Service-instance (type “GenericSubscribeService”). These serv...'

New page

= Architecture of the crawler bundle =

Each 3rd-Party-Service (e.g. Facebook) is represented by a separate
OSGI-Service-instance (type “GenericSubscribeService”). These services
each contain a description (type “CrawlerDescription”) of how to access
“their” 3rd-Party-Service. Every time the OSGI-Bundle
“c.o.subscribe.crawler” is started these descriptions get updated via
reading YML-files (one for each 3rd-Party-Service). So to update a
“Crawler” a new YML-file has to be placed in the appropriate directory
and the OSGI-Bundle has to be restarted.

When a user hits the refresh-button of a subscription the respective
OSGI-Service creates a new workflow-instance (type “Workflow”) from its
description, inserts the user´s credentials (decrypted using his login
password) and executes the workflow. The workflow then executes each each
Step (type “Step”) in order. The output of each step is given to its
successor as input. The output of a workflow´s final step is the wanted
content (e.g. a list of Contacts) and is returned, via the OSGI-Service, to
the OX-Server.

[[File:Crawler_Architecture.jpg]]

← Older revision		Revision as of 10:08, 4 March 2010
Line 2:		Line 2:

	Each 3rd-Party-Service (e.g. Facebook) is represented by a separate		Each 3rd-Party-Service (e.g. Facebook) is represented by a separate
	OSGI-Service-instance (type ~~”GenericSubscribeService”~~). These services		OSGI-Service-instance (type "GenericSubscribeService"). These services
	each contain a description (type ~~“CrawlerDescription”~~) of how to access		each contain a description (type "CrawlerDescription") of how to access
	~~“their”~~ 3rd-Party-Service. Every time the OSGI-Bundle		"their" 3rd-Party-Service. Every time the OSGI-Bundle
	~~“com~~.openexchange.subscribe.~~crawler”~~ is started these descriptions get updated via		"com.openexchange.subscribe.crawler" is started these descriptions get updated via
	reading YML-files (one for each 3rd-Party-Service). So to update a		reading YML-files (one for each 3rd-Party-Service). So to update a
	~~“Crawler”~~ a new YML-file has to be placed in the appropriate directory		"Crawler" a new YML-file has to be placed in the appropriate directory
	and the OSGI-Bundle has to be restarted.		and the OSGI-Bundle has to be restarted.

	When a user hits the refresh-button of a subscription the respective		When a user hits the refresh-button of a subscription the respective
	OSGI-Service creates a new workflow-instance (type ~~“Workflow”~~) from its		OSGI-Service creates a new workflow-instance (type "Workflow") from its
	description, inserts the user´s credentials (decrypted using his login		description, inserts the user´s credentials (decrypted using his login
	password) and executes the workflow. The workflow then executes each each		password) and executes the workflow. The workflow then executes each each
	Step (type ~~“Step”~~) in order. The output of each step is given to its		Step (type "Step") in order. The output of each step is given to its
	successor as input. The output of a ~~workflow´s~~ final step is the wanted		successor as input. The output of a workflow's final step is the wanted
	content (e.g. a list of Contacts) and is returned, via the OSGI-Service, to		content (e.g. a list of Contacts) and is returned, via the OSGI-Service, to
	the OX-Server.		the OX-Server.