Rapha�l Luta wrote:

> Todd Kuebler wrote:
>
>> Ok, finally had a chance to dig around in the Capability Map stuff in 
>> both jetspeed and the portal API areas.
>>
>> I definately agree that the capability map direction is the one to go 
>> to add the features contained in my proposal.
>>
>> I have a few questions:
>>
>> 1) If I read the code right, no changes to either the Template or 
>> Profile Locators would be necessary if the directory structure 
>> continues to include media-type with no additional directories added 
>> to the heirarchy for browser.  Am I missing anything?  It looks like 
>> if the media-type is defined correctly based on user-agent -> 
>> media-type mapping it would just work.
>>
>
> I think for the convenience of portal developers and site maintainers 
> you'll
> need to implement a more sophisticated media-type matching capability 
> that the
> current "only match if strictly equal" policy.
> Why ? Because if you want to differentiate between very close 
> media-types to adjust
> for some client bugs (ie the Netscape table implementation bug), 
> you'll probably
> want to use a single PSML resource but different template resources.
>
> You can achieve that if your media matching algorithm returns an 
> ordered list of
> suitable media-types so that you can have fallbacks in your PSML 
> resource search or
> your template resource search...
>
>> 2) Shouldn't the capability map be in the registry as a separate 
>> entity instead of a properties file or hardcoded?  Or should those 
>> capability definitions be hardcoded/properties as Ralpael's previous 
>> message and the Portal API imply?  I can imagine needing to define 
>> additional capabilities, so that would point to the former.
>>
>
> Correct, there's already an updated implementation available, see below.
>
>> 3) It looks like the current media-type registry is simply tied to 
>> content-type.  This might imply that there needs to be a content-type 
>> registry, a capability registry, and the media-type registry would 
>> just tie these together.
>>
>
> I'm not sure we really need a content-type & capability registry as
> independant entities but media-type definitely needs to be expanded to
> include content & capability.
> Why would you introduce a content-type registry or a capability 
> registry ?
>
>> 4) What if a particular user wants to set her add or reduce her 
>> capability to something other than what her user agent maps to?  
>> Should this ability be included in the proposal?
>>
>
> She would use an explicit 'media-type' parameter in the jetspeed URL.
> This explicit parameter should take preference on the computed default
> media-type for the user-agent.
>
>>
>> So the basic approach to implementation seems to be (contingent on 
>> the answers to the questions above):
>>
>> 1) Move the Capability Map into registry.
>
>
> This has already been implemented by Stephan Hesmer in the 'portlet_api'
> branch. I've retrieved this code and ported it to the current CVS head 
> for
> your convenience :)
> I expect to commit it over the week-end or on Monday.


Hi, Raphael, while you are at this, I had a patch for specifying a 
characterSet in the Media registry. I was about to commit a JR.p setting 
for this, but I noticed that it really was part of the Media type. What 
do you think?

The changes are tested, but they will surely interfere with your pending 
changes, so I thought better to make you have a look at them.

It will enable to set the character set correctly also (this we have 
broken, as far as I know).

If you like it and there is no interference, I can commit this myself 
(unless you have punished me and suspended my account for being away too 
much time ;)

This is part of my patches cleanup, and I would be glad if you integrate 
it (or something along the lines). Our non-ISO-8859-1 users will surely 
like something along the lines.

>
>> 2) Add a content-type registry
>
>
> I think this is really optional
>
>
>> 3) Change the media-type entries to define a collection if 
>> content-type(1)/user-agent(*)/capability(*) instead.
>
>
> Yes this needs to be done. I may help here.
>
>> 4) Get the media-type set correctly in the rundata on login based on 
>> the user agent.
>
>
> +1
>
>> 5) Test to verify that this maps correctly in psml,  jslink and 
>> template realms.
>>
>
> +1
>
>>
>> I would be more than happy to do this work and submit the patches for 
>> your approval, just want to make sure I'm going down the right 
>> path.   I'll submit a more detailed, modified proposal once I have 
>> some of these questions more solidified.
>>
>


Attachment: diffsDefineteMimeTypeCharSet
Description: application/java-vm

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to