Hi James,

James Carlson ??:
> chenpu writes:
>   
>> James Carlson ??????:
>>     
>>> Yong Sun writes:
>>>   
>>>       
>>>> I may not get your points, as my understanding, the documents (in SGML 
>>>> format, or html format, or any formats could be handled by Lucene) are 
>>>> parsed and processed in an off-line manner, which would not run on the 
>>>> server.
>>>>     
>>>>         
>>> What processes these files, and what assumptions does it make?
>>>   
>>>       
>> There are some scripts to parse the source SGML file and generate index 
>> files. Those SGML are from IPG(doc team) and G11n(localized documents) 
>> directly. Since this case is just for client app, I did not list them in 
>> the one pager.
>>     
>
> Is the DTD used there a public interface?
>   

>   
>>> Is this project related to "Sun i-Runbook" (maybe a replacement)?
>>>   
>>>       
>> No.
>>     
>>> Is Lucene delivered in a way that others can use it?  Should it be?
>>>   
>>>       
>> Lucene will not be use on server side. That means it will not be 
>> delivered to Opensolaris.
>>     
>
> I'm confused.  Do you mean to say that it won't be used on either the
> client or the server?  If so, then why is it part of this case?  (Or
> is it no longer part of this case?)
>
> (Maybe the above should say "will be used on the server side" rather
> than "will not be use on server side" ... but I'm lost.)
>   
Sorry, it's a typo. Lucene will only be used on server side. ;-)
>   
>>> Can users set up their own servers or is that a "Sun only" operation?
>>> I would expect that to be a hard requirement for many customers, as
>>> allowing direct Internet access from within a datacenter is still not
>>> possible in many places.
>>>   
>>>       
>> It's a "Sun only" operation for setting up Web Server. You know the 
>> volumes for contents are big, it's impossible to put them into client 
>> app for off-line review.
>>     
>
> That makes the architecture even less obvious to me.
>
>   
>>> How does the user specify where he gets his information (which server
>>> to use)?
>>>   
>>>       
>> The server info will be hard coded into the client app.
>>     
>
> Oh.
>
>   
>>> I still don't quite see how the proposed project is "obvious" enough
>>> to be a fast-track.  Why not run a full case for it?
>>>   
>>>       
>> Thanks for the suggestion, James. Can you help to be sponsor for this 
>> case? Or we can get somebody's help on this?
>>     
>
> Your fast-track sponsor should have helped out with the process, and
> directed you to a 1-pager.
>
> I'm derailing this case because it doesn't appear to be a fast-track
> in scope, and I'm finding out too much in bits and pieces; a meeting
> would be more productive.
>
> That means it's now a full case and (at least by tradition) I'm the
> case owner.  (If you prefer a different owner, that'd be fine by me;
> just look at the member list for any ARC and select someone you
> prefer.)
>
> The next step for you is to check the PSARC agenda and decide when you
> could be ready for a review.  When you decide, send email to
> psarc-agenda at sac.sfbay to schedule the review.  Your materials will
> normally need to be ready one week in advance of that date, but that
> can be altered if necessary.  (It's not clear to me that your current
> materials are complete; we seem to be lacking scope information.)
>
> The current schedule has a lack of meetings until January 14th.  The
> usual rule is to "ARC early," but if there are schedule problems
> because of this unusual situation, I'm sure we can work around that by
> scheduling an extra meeting date.  Contact the PSARC chair to do that
> or to work around other scheduling issues (such as time-of-day).
>
>   
Thanks for the infos. We will have a discussion on this and get back to 
you.

Regards,
Jeffrey


Reply via email to