| 309 |
because improves the overall quality of content-based content type lookups.</p> |
because improves the overall quality of content-based content type lookups.</p> |
| 310 |
</li> |
</li> |
| 311 |
</ol> |
</ol> |
| 312 |
<p> |
<p> <em>Note: comments are encouraged. Any questions/concerns not addressed here |
| 313 |
<em>Note: comments are encouraged. Any questions/concerns not addressed here should be discussed in the platform-core-dev list, |
should be discussed in the platform-core-dev list, or bug <a |
| 314 |
or bug <a |
href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37668">37668</a>. </em></p> |
| 315 |
href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=37668">37668</a>. |
<h2>Addendum: issues to be addressed in the 3.1 cycle</h2> |
| 316 |
</em></p> |
<p><font size="-1">Last modified: October 15th, 2004</font></p> |
| 317 |
|
<p>The solution described above was implemented and relatively succesful. Some |
| 318 |
|
components took advantage of the new content type infrastructure, but still |
| 319 |
|
in many cases file-association is being done in an ad-hoc manner. Also, no UI |
| 320 |
|
was provided for customizing content types (such as changing the default encoding, |
| 321 |
|
adding associations with files) so the user has no control on how the content |
| 322 |
|
type detection mechanism works. Thus, the main issues to be addressed in the |
| 323 |
|
3.1 cycle are:</p> |
| 324 |
|
<ul> |
| 325 |
|
<li>ensure the content type framework works for clients that have not adopted |
| 326 |
|
it yet, or at least we understand why it is not (cannot be made) suitable |
| 327 |
|
to them. Examples are: Platform/UI, Platform/CVS, and products built on top |
| 328 |
|
of Eclipse.</li> |
| 329 |
|
<li>ensure users are granted appropriate means so they can customize the behavior |
| 330 |
|
of content type detection so things just work for them.</li> |
| 331 |
|
<li>ensure content type resolution works (or can be made to work) appropriately |
| 332 |
|
in setups where multiple independently developed products contribute conflicting |
| 333 |
|
content types. </li> |
| 334 |
|
</ul> |
| 335 |
|
<h3>Support more use cases</h3> |
| 336 |
|
<p>Ensure the Content Type works for the SDK plug-ins and for products built on |
| 337 |
|
top of Eclipse.</p> |
| 338 |
|
<p><strong>Platform/UI - file/editor association</strong></p> |
| 339 |
|
<p><strong>Platform/Team - binary vs ascii files</strong></p> |
| 340 |
|
<h3>Give users more power</h3> |
| 341 |
|
<p>Ensure users have means to customize how the content type detection works |
| 342 |
|
for them.</p> |
| 343 |
|
<h3>Improve conflict handling</h3> |
| 344 |
|
<p>Ensure content type detection works (or can be made to work) appropriately |
| 345 |
|
when incompatible products are deployed together.</p> |
| 346 |
</body></html> |
</body></html> |