Talk:PropertyFiles - Revision history

Apidesign: Reverted edits by 218.6.12.69 (Talk); changed back to last version by 59.58.137.216

2012-09-19T10:27:49Z

Reverted edits by 218.6.12.69 (Talk); changed back to last version by 59.58.137.216

←Older revision		Revision as of 10:27, 19 September 2012
Line 74:		Line 74:

	--Assovorge 19:54, 17 February 2012 (CET)		--Assovorge 19:54, 17 February 2012 (CET)
-	~~</div>~~
-	~~== Emusiabub said ... ==~~
-
-	~~<div class='commentBlock'>~~
-	寄宿舎の何百もの全国稼動している。これらの施設のスタッフは動物のための彼らの愛の職業を作っており、あなたの犬の仲間のために仮設住宅を提供するために幸せになる。どこでも十から百匹の犬は、施設の規模に応じて、任意の時点での住居であってもよく、コストは場所によって異なります。
-
-	~~http://www.chloetojp.com/ クロエアウトレット~~
-	~~http://www.chloetojp.com/ クロエ財布~~
-	~~http://www.chloetojp.com/ クロエバッグ~~
-	~~http://www.chloetojp.com/ クロエ~~
-	~~http://www.chloetojp.com/ クロエ長財布~~
-	~~クロエ: http://www.chloetojp.com/~~
-
-
-
-	~~--[http://www.chloetojp.com/~~
-	~~Emusiabub] 03:47, 19 September 2012 (CEST)~~
	</div>		</div>

218.6.12.69: Comment provided by Emusiabub - via ArticleComments extension

2012-09-19T01:47:13Z

Comment provided by Emusiabub - via ArticleComments extension

←Older revision		Revision as of 01:47, 19 September 2012
Line 74:		Line 74:

	--Assovorge 19:54, 17 February 2012 (CET)		--Assovorge 19:54, 17 February 2012 (CET)
		+	</div>
		+	== Emusiabub said ... ==
		+
		+	<div class='commentBlock'>
		+	寄宿舎の何百もの全国稼動している。これらの施設のスタッフは動物のための彼らの愛の職業を作っており、あなたの犬の仲間のために仮設住宅を提供するために幸せになる。どこでも十から百匹の犬は、施設の規模に応じて、任意の時点での住居であってもよく、コストは場所によって異なります。
		+
		+	http://www.chloetojp.com/ クロエアウトレット
		+	http://www.chloetojp.com/ クロエ財布
		+	http://www.chloetojp.com/ クロエバッグ
		+	http://www.chloetojp.com/ クロエ
		+	http://www.chloetojp.com/ クロエ長財布
		+	クロエ: http://www.chloetojp.com/
		+
		+
		+
		+	--[http://www.chloetojp.com/
		+	Emusiabub] 03:47, 19 September 2012 (CEST)
	</div>		</div>

59.58.137.216: Comment provided by Assovorge - via ArticleComments extension

2012-02-17T18:54:20Z

Comment provided by Assovorge - via ArticleComments extension

←Older revision		Revision as of 18:54, 17 February 2012
Line 67:		Line 67:
	Thanks for your comment.		Thanks for your comment.
	--[[User:JaroslavTulach\|JaroslavTulach]] 18:51, 28 November 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 18:51, 28 November 2010 (UTC)
		+	</div>
		+	== Assovorge said ... ==
		+
		+	<div class='commentBlock'>
		+	Hello. And Bye.
		+
		+	--Assovorge 19:54, 17 February 2012 (CET)
	</div>		</div>

Apidesign: Reverted edits by 94.100.25.194 (Talk); changed back to last version by JaroslavTulach

2011-02-26T06:53:18Z

Reverted edits by 94.100.25.194 (Talk); changed back to last version by JaroslavTulach

←Older revision		Revision as of 06:53, 26 February 2011
Line 67:		Line 67:
	Thanks for your comment.		Thanks for your comment.
	--[[User:JaroslavTulach\|JaroslavTulach]] 18:51, 28 November 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 18:51, 28 November 2010 (UTC)
-	~~</div>~~
-	~~== Eminnahiz said ... ==~~
-
-	~~<div class='commentBlock'>~~
-	~~http://oemsoft4you.com/brand/abacre/abacre_advanced_log_analyzer_2_0_windows/ - Buy cheap Abacre Advanced Log Analyzer 2.0 Oem Software Version~~
-	~~http://oemsoft4you.com/brand/steinberg/clean_3_0/ - Buy cheap Steinberg Clean 3.0 Oem Software Version~~
-	~~http://oemsoft4you.com/brand/idm/ultraedit_16_20_0_1011/ - Buy cheap IDM UltraEdit 16.20.0.1011 Oem Software Version~~
-	~~http://oemsoft4you.com/brand/steinberg/nuendo_4_3/ - Buy cheap Steinberg Nuendo 4.3 Oem Software Version~~
-	~~http://oemsoft4you.com/brand/abyssmedia/abyssmedia_msi_to_exe_compiler_1_2_0_1_windows/ - Buy cheap Abyssmedia MSI to EXE Compiler 1.2.0.1 Oem Software Version~~
-
-
-	~~--[http://oemsoft4you.com/brand/4videosoft/4videosoft_walkman_video_converter_3_2_06_windows/~~
-	~~Eminnahiz] 11:20, 22 February 2011 (CET)~~
	</div>		</div>

94.100.25.194: Comment provided by Eminnahiz - via ArticleComments extension

2011-02-22T10:20:40Z

Comment provided by Eminnahiz - via ArticleComments extension

←Older revision		Revision as of 10:20, 22 February 2011
Line 67:		Line 67:
	Thanks for your comment.		Thanks for your comment.
	--[[User:JaroslavTulach\|JaroslavTulach]] 18:51, 28 November 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 18:51, 28 November 2010 (UTC)
		+	</div>
		+	== Eminnahiz said ... ==
		+
		+	<div class='commentBlock'>
		+	http://oemsoft4you.com/brand/abacre/abacre_advanced_log_analyzer_2_0_windows/ - Buy cheap Abacre Advanced Log Analyzer 2.0 Oem Software Version
		+	http://oemsoft4you.com/brand/steinberg/clean_3_0/ - Buy cheap Steinberg Clean 3.0 Oem Software Version
		+	http://oemsoft4you.com/brand/idm/ultraedit_16_20_0_1011/ - Buy cheap IDM UltraEdit 16.20.0.1011 Oem Software Version
		+	http://oemsoft4you.com/brand/steinberg/nuendo_4_3/ - Buy cheap Steinberg Nuendo 4.3 Oem Software Version
		+	http://oemsoft4you.com/brand/abyssmedia/abyssmedia_msi_to_exe_compiler_1_2_0_1_windows/ - Buy cheap Abyssmedia MSI to EXE Compiler 1.2.0.1 Oem Software Version
		+
		+
		+	--[http://oemsoft4you.com/brand/4videosoft/4videosoft_walkman_video_converter_3_2_06_windows/
		+	Eminnahiz] 11:20, 22 February 2011 (CET)
	</div>		</div>

JaroslavTulach at 18:55, 28 November 2010

2010-11-28T18:55:04Z

←Older revision		Revision as of 18:55, 28 November 2010
Line 61:		Line 61:
	--[http://passion.forco.de/ Ansgar Konermann] 17:34, 25 November 2010 (CET)		--[http://passion.forco.de/ Ansgar Konermann] 17:34, 25 November 2010 (CET)

-	Hello Ansgar, I think you are right. The most important thing is to keep the user '''informed'''. Probably the [[OSGi]] spec, tools, impls could do better job. However my point is that having the version identification attribute present (and required) since first version makes your life easier. This is not that visible in case of [[PropertyFiles]], where it is relatively easy to add new attribute in (almost ~ 99%) compatible way~~, but~~ in case of binary formats, it is essential to get the version right as soon as possible, otherwise one can completely loose offset and interpret the content completely incorrectly.	+	Hello Ansgar, I think you are right. The most important thing is to keep the user '''informed'''. Probably the [[OSGi]] spec, tools, impls could do better job. However my point is that having the version identification attribute present (and required) since first version makes your life easier. This is not that visible in case of [[PropertyFiles]], where it is relatively easy to add new attribute in (almost ~ 99%) compatible way. However in case of binary formats, it is essential to get the version right as soon as possible, otherwise one can completely loose offset and interpret the content completely incorrectly. Without knowing that 3rd byte of the file represents a version, it is really tough job.

-	Btw. your fix is not 100% [[BackwardCompatibility\|compatible]]: In old version I might accidently use one of the added attributes for completely unrelated purposes. If I then upgrade ~~the~~ [[OSGi]] container to new version, it will complain and refuse my bundle which used to ~~run~~ in previous version. I guess this is the reason why new [[OSGi]] specification requires the ''Bundle-Version'' attribute to be present. Guys wanted to be 100% [[BackwardCompatibility\|compatible]].	+	Btw. your fix is not 100% [[BackwardCompatibility\|compatible]]: In old version I might accidently use one of the (in future) added attributes for completely unrelated purposes. If I then upgrade my [[OSGi]] container to new version, it will complain about incorrect syntax (or whatsoever) and refuse my bundle which used to be completely fine in previous version. I guess this is the reason why new [[OSGi]] specification requires the ''Bundle-Version'' attribute to be present. Guys wanted to be 100% [[BackwardCompatibility\|compatible]] and traded that for keeping user "informed" (yes, they still could do a better job and at least print a warning).

	Thanks for your comment.		Thanks for your comment.
	--[[User:JaroslavTulach\|JaroslavTulach]] 18:51, 28 November 2010 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 18:51, 28 November 2010 (UTC)
	</div>		</div>

JaroslavTulach at 18:52, 28 November 2010

2010-11-28T18:52:04Z

←Older revision		Revision as of 18:52, 28 November 2010
Line 61:		Line 61:
	--[http://passion.forco.de/ Ansgar Konermann] 17:34, 25 November 2010 (CET)		--[http://passion.forco.de/ Ansgar Konermann] 17:34, 25 November 2010 (CET)

-	Hello Ansgar, I think you are right. The most important thing is to keep the user '''informed'''. Probably the [[OSGi]] spec, tools, impls could do better job. However my point is that having the version present (and required) since first version makes your life easier. This is not that visible in case of [[PropertyFiles]], where it is relatively easy to add new attribute in (almost ~ 99%) compatible way, but in case of binary formats, it is essential to get the version right as soon as possible, otherwise one can completely loose offset and interpret the content completely incorrectly.	+	Hello Ansgar, I think you are right. The most important thing is to keep the user '''informed'''. Probably the [[OSGi]] spec, tools, impls could do better job. However my point is that having the version identification attribute present (and required) since first version makes your life easier. This is not that visible in case of [[PropertyFiles]], where it is relatively easy to add new attribute in (almost ~ 99%) compatible way, but in case of binary formats, it is essential to get the version right as soon as possible, otherwise one can completely loose offset and interpret the content completely incorrectly.

	Btw. your fix is not 100% [[BackwardCompatibility\|compatible]]: In old version I might accidently use one of the added attributes for completely unrelated purposes. If I then upgrade the [[OSGi]] container to new version, it will complain and refuse my bundle which used to run in previous version. I guess this is the reason why new [[OSGi]] specification requires the ''Bundle-Version'' attribute to be present. Guys wanted to be 100% [[BackwardCompatibility\|compatible]].		Btw. your fix is not 100% [[BackwardCompatibility\|compatible]]: In old version I might accidently use one of the added attributes for completely unrelated purposes. If I then upgrade the [[OSGi]] container to new version, it will complain and refuse my bundle which used to run in previous version. I guess this is the reason why new [[OSGi]] specification requires the ''Bundle-Version'' attribute to be present. Guys wanted to be 100% [[BackwardCompatibility\|compatible]].

JaroslavTulach at 18:51, 28 November 2010

2010-11-28T18:51:26Z

←Older revision		Revision as of 18:51, 28 November 2010
Line 63:		Line 63:
	Hello Ansgar, I think you are right. The most important thing is to keep the user '''informed'''. Probably the [[OSGi]] spec, tools, impls could do better job. However my point is that having the version present (and required) since first version makes your life easier. This is not that visible in case of [[PropertyFiles]], where it is relatively easy to add new attribute in (almost ~ 99%) compatible way, but in case of binary formats, it is essential to get the version right as soon as possible, otherwise one can completely loose offset and interpret the content completely incorrectly.		Hello Ansgar, I think you are right. The most important thing is to keep the user '''informed'''. Probably the [[OSGi]] spec, tools, impls could do better job. However my point is that having the version present (and required) since first version makes your life easier. This is not that visible in case of [[PropertyFiles]], where it is relatively easy to add new attribute in (almost ~ 99%) compatible way, but in case of binary formats, it is essential to get the version right as soon as possible, otherwise one can completely loose offset and interpret the content completely incorrectly.

-	Btw. your fix is not 100% [[~~backwardcompatible~~]]: In old version I might accidently use one of the added attributes for completely unrelated purposes. If I then upgrade the [[OSGi]] container to new version, it will complain and refuse my bundle which used to run in previous version. I guess this is the reason why new [[OSGi]] specification requires the ''Bundle-Version'' attribute to be present. Guys wanted to be 100% [[~~backwardcompatible~~]].	+	Btw. your fix is not 100% [[BackwardCompatibility\|compatible]]: In old version I might accidently use one of the added attributes for completely unrelated purposes. If I then upgrade the [[OSGi]] container to new version, it will complain and refuse my bundle which used to run in previous version. I guess this is the reason why new [[OSGi]] specification requires the ''Bundle-Version'' attribute to be present. Guys wanted to be 100% [[BackwardCompatibility\|compatible]].
		+
		+	Thanks for your comment.
		+	--[[User:JaroslavTulach\|JaroslavTulach]] 18:51, 28 November 2010 (UTC)
	</div>		</div>

JaroslavTulach at 18:50, 28 November 2010

2010-11-28T18:50:42Z

←Older revision		Revision as of 18:50, 28 November 2010
Line 60:		Line 60:

	--[http://passion.forco.de/ Ansgar Konermann] 17:34, 25 November 2010 (CET)		--[http://passion.forco.de/ Ansgar Konermann] 17:34, 25 November 2010 (CET)
		+
		+	Hello Ansgar, I think you are right. The most important thing is to keep the user '''informed'''. Probably the [[OSGi]] spec, tools, impls could do better job. However my point is that having the version present (and required) since first version makes your life easier. This is not that visible in case of [[PropertyFiles]], where it is relatively easy to add new attribute in (almost ~ 99%) compatible way, but in case of binary formats, it is essential to get the version right as soon as possible, otherwise one can completely loose offset and interpret the content completely incorrectly.
		+
		+	Btw. your fix is not 100% [[backwardcompatible]]: In old version I might accidently use one of the added attributes for completely unrelated purposes. If I then upgrade the [[OSGi]] container to new version, it will complain and refuse my bundle which used to run in previous version. I guess this is the reason why new [[OSGi]] specification requires the ''Bundle-Version'' attribute to be present. Guys wanted to be 100% [[backwardcompatible]].
	</div>		</div>

80.86.190.132: Comment provided by Ansgar Konermann - via ArticleComments extension

2010-11-25T16:34:43Z

Comment provided by Ansgar Konermann - via ArticleComments extension

←Older revision		Revision as of 16:34, 25 November 2010
Line 39:		Line 39:

	--[http://apidesign.org JaroslavTulach] 14:39, 19 December 2008 (CET)		--[http://apidesign.org JaroslavTulach] 14:39, 19 December 2008 (CET)
		+	</div>
		+	== Ansgar Konermann said ... ==
		+
		+	<div class='commentBlock'>
		+	Hi Jaroslav,
		+
		+	what if a developer accidentally specifies a wrong Bundle-ManifestVersion value? The Require-Bundle tag would still be ignored!
		+
		+	To me, merely making the Bundle-ManifestVersion header mandatory from version 1 on does not help very much in practice.
		+
		+	Instead, the user of the API should be informed if the service providing this API detects "inconsistent use" of different versions of the API. In this case: the OSGi container or bundling tool should warn at packaging or deployment time if one tries to create/use a bundle without Bundle-ManifestVersion specified, but containing tags from "non-1.0" API versions inside the bundle manifest.
		+
		+	This is similar to a "syntax check" done by programming language compilers. If our OSGi tooling does not support this syntax check (yet?), at least the runtime container should do.
		+
		+	The point I'm trying to make is: let's not blame the API specification for a missing mechanism which can ensure that the API is used correctly.
		+
		+	Best regards
		+
		+	Ansgar
		+
		+	--[http://passion.forco.de/ Ansgar Konermann] 17:34, 25 November 2010 (CET)
	</div>		</div>