I've updated the one page and summarized the question and answers.

Q1. There are some similar functionality projects.

    I'v listed the known project with similar function in the ARC material.

Q2. Mime type file extension conflicts.
   
    There is a potential Mime Type conflicts when integrating projects with
    overlap functionality. Although Planner (LSARC/2008/454) and Openproj
    are both project management tools, but they have their own file format
    and different file extensions, *.planner and *mrprojects for Planner,
    *.pod for Openproj.  There are no Mime type conflicts for Planner 
and Openproj.
    I'll keep my eyes on this kind of stuff in future.

Thanks
Jim


> Usually the "default app" is a user preference. As long as there is no 
> conflict between the apps I think its ok to have as many as people 
> want. I think the important part is making sure the default is easily 
> changeable. I hate to use it as an example but Windows has the default 
> programs control panel and also has some right menu selections that 
> let you "Open file with..." type functionality so you can override the 
> default when required. I'm pretty sure that functionality is already 
> in gnome but it would be nice to have that confirmed as we add 
> different packages with overlapping functionality.
>
> Which one we decide to make default is an other question. I'd vote 
> "None of the above" and make the user pick except in the most obvious 
> cases.
>
> Edward Hunter wrote:
>> It seems like there is a business issue and an architectural issue 
>> combined here.  The business issue is which consumer of the mime type 
>> (or media format) does Sun pick as the winner.  That would be the 
>> default out of the box.  We could of course choose not to pick one 
>> and that is a decision too.  :-)
>>
>> The architectural question seems to be "if you pick a winner, does 
>> that have a bad effect on the losers".  In other words does picking A 
>> prevent B and C from functioning.  It sounds like in this case the 
>> business case is to not pick a winner since we're integrating both 
>> bits of software.  What is not clear to me is the side effects when 
>> the end user chooses between the two (or three) choices.  In 
>> particular if different users on the same system choose different 
>> defaults is that a problem?  Sounds like no but I am not sure.
>> -edh
>>
>>
>> Torrey McMahon wrote:
>>> Jim Li wrote:
>>>> Torrey:
>>>>>>> Not to start a flame-fest here but haven't we seen a lot of 
>>>>>>> other projects come across lately that integrate functionality 
>>>>>>> that matches an other project? Why would this be different?
>>>>>>
>>>>>> I don't think it is a problem to have duplicate functionality,
>>>>>> personally.  I would just like to hear that the project teams 
>>>>>> delivering
>>>>>> related projects are talking together and formulating their plans 
>>>>>> with
>>>>>> each other in mind, cooperating with work on any common 
>>>>>> dependencies,
>>>>>> etc.  At least aware of each other. 
>>>>>
>>>>> All of engineering gets the ARC case submittal forms, right? ;)
>>>>>
>>>>> Seriously - I agree with you. One thing I'm sure we'll see is 
>>>>> fighting mime types of file extensions in a lot of cases.
>>>> Mime types of file extensions issue exists in all kind of systems, 
>>>> so IMHO this is not a ARC issue. 
>>>
>>> I'm not sure its *not* an ARC issue but I'm not raising it for this 
>>> case. My point is that as we - And this is a generalization - add 
>>> every single piece of FOSS software we can get our hands on to 
>>> [Open]Solaris we're going to see more conflicts then we did in the 
>>> past. The past being known for a lot less duplication and an 
>>> unwillingness to have more then one tool do the same job.
>>>
>>> Media players are the easy example. How many have we integrated now? 
>>> How is a user going to select the one they want and make it the 
>>> default? Again, not a question for this case or this project team, 
>>> but something we should figure out in the near term....if someone 
>>> hasn't already.
>>>
>>>
>>>
>


Reply via email to