Protocol requirements - Revision history

142.177.74.77 at 22:14, 10 April 2004

2004-04-10T22:14:07Z

← Older revision		Revision as of 22:14, 10 April 2004
Line 19:		Line 19:
	:::Ideally since we have drifted from syntactically strict data format into [[wiki code]] that is easier for human cognition we should try to offer the '''avantgarde consumerist''' information and then rely on people getting into discussions over/on the information thus the [[healthy signal infrastructure]] is extended by word-of-mouth.		:::Ideally since we have drifted from syntactically strict data format into [[wiki code]] that is easier for human cognition we should try to offer the '''avantgarde consumerist''' information and then rely on people getting into discussions over/on the information thus the [[healthy signal infrastructure]] is extended by word-of-mouth.

	[[Hardware requirements]] and [[hardware standard]]s constrain the protocols: [[Bluetooth]] for instance is assumed to be required to get both secure communication and [[modular hardware]]. But if [[in-store radio]] and [[audio]] presentation becomes a more effective way to deliver the [[Consumerium buying signal]], and [[privacy risk]] is not a concern, i.e. most of what is delivered is [[green light ad]]s, then:		[[Hardware requirements]] and [[hardware standard]]s constrain the protocols: [[Bluetooth]] or [[DECT]] for instance is assumed to be required to get both secure communication and [[modular hardware]]. But if [[in-store radio]] and [[audio]] presentation becomes a more effective way to deliver the [[Consumerium buying signal]], and [[privacy risk]] is not a concern, i.e. most of what is delivered is [[green light ad]]s, then:

	*In-the-clear [[FM radio]] may well be the most important protocol, with [[analog cell]] perhaps augmenting it.		*In-the-clear [[FM radio]] may well be the most important protocol, with [[analog cell]] perhaps augmenting it.

	*Entirely different protocols such as [[walkie-talkie]] or [[cordless protocol]] applications that call the customer back with an [[audio]] presentation on the product they just [[barcode scan]]ned, may also be more useful to support than anything based on an [[IP number]], if more phones end up with these capabilities.		*Entirely different protocols such as [[walkie-talkie]] or [[cordless protocol]] applications that call the customer back with an [[audio]] presentation on the product they just [[barcode scan]]ned, may also be more useful to support than anything based on an [[IP number]], if more phones end up with these capabilities.

142.177.74.77 at 22:13, 10 April 2004

2004-04-10T22:13:13Z

← Older revision		Revision as of 22:13, 10 April 2004
Line 5:		Line 5:
	*[[HTTP]] and [[REST]] to the [[web browser]], as typical access to [[Development Wiki]] and [[Research Wiki]].		*[[HTTP]] and [[REST]] to the [[web browser]], as typical access to [[Development Wiki]] and [[Research Wiki]].

	*Each high-capability [[terminal device]] presenting a [[Consumerium buying signal]] ~~probably has~~ an [[IP number]] issued from a block someone controls. Every [[retail shelf]] might ultimately have one too, if [[friendly retail]] becomes the norm.		*[[Voice]] (or at least [[touchtone]]) control and [[audio]] communication to a [[headset]] for [[eyesfree]] and [[handsfree]] use at the [[retail shelf]] and [[checkout counter]], where people are typically too busy to look at screens.

			::[[DECT]] seems like the ideal way to provide both of these sets of services

			Beyond that, the following are optional:

			*Each high-capability [[terminal device]] presenting a [[Consumerium buying signal]] might have an [[IP number]] issued from a block someone controls. Every [[retail shelf]] might ultimately have one too, if [[friendly retail]] becomes the norm.

	*Ideally, some integration with [[ICQ]] or another [[chat net]] that can support [[SecureIM]] - see [[interwiki identity standard]] for more on this, which suggests [[jabber.org]] protocol may play a role in [[authentication]]. Possibly [[SMS]] also for communication between [[mobile device]]s.		*Ideally, some integration with [[ICQ]] or another [[chat net]] that can support [[SecureIM]] - see [[interwiki identity standard]] for more on this, which suggests [[jabber.org]] protocol may play a role in [[authentication]]. Possibly [[SMS]] also for communication between [[mobile device]]s.

Jukeboksi: people talking with each other is also a powerful medium/protocol ;) .

2004-03-10T12:36:48Z

people talking with each other is also a powerful medium/protocol ;) .

← Older revision		Revision as of 12:36, 10 March 2004
Line 10:		Line 10:

	::[[Consumerium Service access]] should include access to other users, especially if [[brand management]] types can pay to promote [[green light]] products to users, making it all [[self-funding]].		::[[Consumerium Service access]] should include access to other users, especially if [[brand management]] types can pay to promote [[green light]] products to users, making it all [[self-funding]].

			:::Ideally since we have drifted from syntactically strict data format into [[wiki code]] that is easier for human cognition we should try to offer the '''avantgarde consumerist''' information and then rely on people getting into discussions over/on the information thus the [[healthy signal infrastructure]] is extended by word-of-mouth.

	[[Hardware requirements]] and [[hardware standard]]s constrain the protocols: [[Bluetooth]] for instance is assumed to be required to get both secure communication and [[modular hardware]]. But if [[in-store radio]] and [[audio]] presentation becomes a more effective way to deliver the [[Consumerium buying signal]], and [[privacy risk]] is not a concern, i.e. most of what is delivered is [[green light ad]]s, then:		[[Hardware requirements]] and [[hardware standard]]s constrain the protocols: [[Bluetooth]] for instance is assumed to be required to get both secure communication and [[modular hardware]]. But if [[in-store radio]] and [[audio]] presentation becomes a more effective way to deliver the [[Consumerium buying signal]], and [[privacy risk]] is not a concern, i.e. most of what is delivered is [[green light ad]]s, then:

142.177.76.153: adding performance requirements

2004-03-10T04:53:19Z

adding performance requirements

← Older revision		Revision as of 04:53, 10 March 2004
Line 1:		Line 1:
	''See also [[software requirements]] and [[hardware requirements]].''		''See also [[performance requirements]], [[software requirements]] and [[hardware requirements]].''

	'''Protocol requirements''' for the [[healthy buying infrastructure]] seem to include at least:		'''Protocol requirements''' for the [[healthy buying infrastructure]] seem to include at least:

142.177.76.153 at 04:36, 10 March 2004

2004-03-10T04:36:54Z

← Older revision		Revision as of 04:36, 10 March 2004
Line 3:		Line 3:
	'''Protocol requirements''' for the [[healthy buying infrastructure]] seem to include at least:		'''Protocol requirements''' for the [[healthy buying infrastructure]] seem to include at least:

	*~~Each high-capability~~ [[~~terminal device~~]] ~~involved probably has an~~ [[~~IP number~~]] ~~issued from a block someone controls. Every~~ [[~~retail shelf~~]] ~~might ultimately have one too~~, if [[~~friendly retail~~]] ~~becomes the norm~~.		*[[HTTP]] and [[REST]] to the [[web browser]], as typical access to [[Development Wiki]] and [[Research Wiki]].

	*~~Some integration with~~ [[~~ICQ~~]] ~~or another~~ [[~~chat net~~]] ~~that can support~~ [[~~SecureIM~~]] - [[~~Consumerium Service access~~]] ~~should include access to other users~~, ~~especially~~ if [[~~brand management]] types can pay to promote [[green light]] products to users, making it all [[self-funding~~]].		*Each high-capability [[terminal device]] presenting a [[Consumerium buying signal]] probably has an [[IP number]] issued from a block someone controls. Every [[retail shelf]] might ultimately have one too, if [[friendly retail]] becomes the norm.

	[[~~Hardware requirements]] and [[hardware standard~~]]~~s constrain the protocols:~~ [[~~Bluetooth~~]] ~~for instance is assumed to be required to get both secure communication and~~ [[~~modular hardware~~]]~~. But if [[in~~-~~store radio]] and~~ [[~~audio~~]] ~~presentation becomes a~~ more ~~effective way to deliver the [[Consumerium buying signal]]~~, ~~and~~ [[~~privacy risk~~]] ~~is not~~ a ~~concern, i.e. most of what is delivered is~~ [[~~green light ad~~]]~~s, then in-the-clear~~ [[~~FM radio~~]] ~~may well be the most important protocol, with~~ [[~~analog cell~~]] ~~perhaps augmenting it~~.		*Ideally, some integration with [[ICQ]] or another [[chat net]] that can support [[SecureIM]] - see [[interwiki identity standard]] for more on this, which suggests [[jabber.org]] protocol may play a role in [[authentication]]. Possibly [[SMS]] also for communication between [[mobile device]]s.

	Entirely different protocols such as [[walkie-talkie]] or [[cordless protocol]] applications that call the customer back with an [[audio]] presentation on the product they just [[barcode scan]]ned, may also ~~alter the picture completely~~.		::[[Consumerium Service access]] should include access to other users, especially if [[brand management]] types can pay to promote [[green light]] products to users, making it all [[self-funding]].

			[[Hardware requirements]] and [[hardware standard]]s constrain the protocols: [[Bluetooth]] for instance is assumed to be required to get both secure communication and [[modular hardware]]. But if [[in-store radio]] and [[audio]] presentation becomes a more effective way to deliver the [[Consumerium buying signal]], and [[privacy risk]] is not a concern, i.e. most of what is delivered is [[green light ad]]s, then:

			*In-the-clear [[FM radio]] may well be the most important protocol, with [[analog cell]] perhaps augmenting it.

			*Entirely different protocols such as [[walkie-talkie]] or [[cordless protocol]] applications that call the customer back with an [[audio]] presentation on the product they just [[barcode scan]]ned, may also be more useful to support than anything based on an [[IP number]], if more phones end up with these capabilities.

142.177.76.153: elaborating, adding FM and walkie-talkie options

2004-03-10T04:32:40Z

elaborating, adding FM and walkie-talkie options

← Older revision		Revision as of 04:32, 10 March 2004
Line 1:		Line 1:
	''See also [[software requirements]] and [[hardware requirements]].''		''See also [[software requirements]] and [[hardware requirements]].''

	'''Protocol requirements''' for the [[healthy buying infrastructure]] seem to include at least ~~[[ICQ]] or another [[chat net]] that can support [[SecureIM]].~~		'''Protocol requirements''' for the [[healthy buying infrastructure]] seem to include at least:

	~~Presumably, each~~ [[terminal device]] involved has an [[IP number]] issued from a block someone controls. Every [[retail shelf]] might ultimately have one too.		*Each high-capability [[terminal device]] involved probably has an [[IP number]] issued from a block someone controls. Every [[retail shelf]] might ultimately have one too, if [[friendly retail]] becomes the norm.

	[[Hardware requirements]] and [[hardware standard]]s ~~drive this to a great degree.~~ [[Bluetooth]] for instance is assumed to be required to get both secure communication and [[modular hardware]].		*Some integration with [[ICQ]] or another [[chat net]] that can support [[SecureIM]] - [[Consumerium Service access]] should include access to other users, especially if [[brand management]] types can pay to promote [[green light]] products to users, making it all [[self-funding]].

			[[Hardware requirements]] and [[hardware standard]]s constrain the protocols: [[Bluetooth]] for instance is assumed to be required to get both secure communication and [[modular hardware]]. But if [[in-store radio]] and [[audio]] presentation becomes a more effective way to deliver the [[Consumerium buying signal]], and [[privacy risk]] is not a concern, i.e. most of what is delivered is [[green light ad]]s, then in-the-clear [[FM radio]] may well be the most important protocol, with [[analog cell]] perhaps augmenting it.

			Entirely different protocols such as [[walkie-talkie]] or [[cordless protocol]] applications that call the customer back with an [[audio]] presentation on the product they just [[barcode scan]]ned, may also alter the picture completely.

142.177.97.132 at 23:58, 21 November 2003

2003-11-21T23:58:50Z

New page

''See also [[software requirements]] and [[hardware requirements]].''

'''Protocol requirements''' for the [[healthy buying infrastructure]] seem to include at least [[ICQ]] or another [[chat net]] that can support [[SecureIM]].

Presumably, each [[terminal device]] involved has an [[IP number]] issued from a block someone controls. Every [[retail shelf]] might ultimately have one too.

[[Hardware requirements]] and [[hardware standard]]s drive this to a great degree. [[Bluetooth]] for instance is assumed to be required to get both secure communication and [[modular hardware]].