At 10:00 AM 7/10/01 +0200, you wrote:
>Atul Dambalkar wrote:
>
>>Hi David,
>>While driving back home, I was thinking about the newly added interfaces in
>>Profile(Service) and PsmlManager(Service). I came up to this. I thought I
>>should write an email, right away, so as to avoid any cofusion with my last
>>email (about GenericPsmlManagerService).
>>Here is what I think:
>>"FallBack Algo" is actually a functionality of Profiler(Service) and it is
>>not the job of the PsmlManager to handle that. PsmlManager(Service) should
>>just manage the PSMLs. So I think PsmlManager(Service) should not have
>>following two methods:
>>1. public Iterator list( ProfileLocator locator ) 2. public PSMLDocument
>>fallback( List locators );
>>Those methods need to be moved to Profiler(Service.
>>The "fallback" method in Profiler(Service) then should invoke
>>PSMLDocument getDocument(ProfileLocator) method to get the appropriate PSML
>>document. I couldn't figure out what structural pattern this would fall
>>under. So basically, the GenericPsmlManagerService which I outlined in my
>>last email is definitely not needed, and above two methods should go in
>>Profiler(Service) and its implementation in JetspeedProfilerService.
>>What are your views on this?
>
>
>+1 for list(locator) being in Profiler. It's definitely Profiler's job to do
>that, although I would amend the interface to
>
>public Iterator list( RunData data, ProfileLocator locator )
>or
>public Iterator list( User user, ProfileLocator locator )
>or
>add a get/setUser() in ProfileLocator to put in the RunData User object.
>
>Why ? Imagine I want to write an alternate adaptive Profiler that stores
>persistent information in the User profile... I need to be able to access
>a pointer to the User.
>... All in all, I think the third option is the best, it replaces the string
>user parameter that was there before and gives a lot more power to the
>profiling interface and enables a trivial implementation of a DB-backed PSML
>implementation (just store PSML as BLOB using setPerm())
>
>What do you think ?
I am okay with the first two options..but I am not able to follow the
third..what it is trying to do?
>As for the second method, I'm +0 where it's located, it can be either in
>Profiler, in which case it would implemented something like:
>
>public PSMLDocument fallback (List loactors)
>{
> Iterator i = locators.iterator();
> PSMLDocument doc = null;
>
> while ((doc == null) && i.hasNext())
> {
> try
> {
> doc = PsmlManager.getDocument((ProfileLocator)i.next());
> }
> catch (Exception e)
> {
> //ignore any exceptions just use next locator
> }
> }
>
> if (doc==null)
> {
> // algorithm failed
> }
>
> return doc;
>}
>
>or directly in PsmlManager interface, in which case it should be called
> IMO:
What is IMO?
>public PSMLDocument getDocument(List locators)
>
>and implemented exactly the same way as above... !
I am still concerned about this method being in PsmlManager...even though
the Profiler is handling creation of ordered list of Locators, the
"fallback" is job of the profiler..
More later...
-Atul
>--
>Raphael Luta - [EMAIL PROTECTED]
>Vivendi Universal Networks - Paris
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
