Re: Bugs, Features, FAQs (1-10)?

Hi

( I've copied this back to the list )

On 27 Mar, Anselm Baird_Smith wrote:
> Joel Crisp writes:
>  > Anslem, do you have the TODO and BUG lists as HTML pages ?
> 
> It 's still in todo ;-)
ROFL

> I have my own todo list, I would reallly like to make it avail in
> jigsaw.w3.org somewhere.

> 
> BTW I have made a new snapshot avail at:
> 
> http://jigsaw.w3.org/Friends/
> check also:
> http://jigsaw.w3.org/status/plan.html
> 
> Anyfeedback welcome

OK, I'll pull it. This is my last day here, but the Linux JDK 1.1
should be out RSN....
Dan Brickley (daniel.brickley@bris.ac.uk) will be talking over some of
the work which I am currently involved in, and Mark Gillett
(mgillett@sghms.ac.uk) will also be involved in London. Things are a
bit complex, as the project managers had a dust-up and Bristol is
pulling out of the project, however two streams of development will
ensue as both sites are continuing with the code. I'll be advising both
of them ! ( And people wonder why I'm leaving... )

> 
>  > If not, had you considered using something like GNATS ?
> 
> Do you have experience with it ? (I don't even know how it looks). Is
> it just a set of CGI scripts ?

It is a set of PERL scripts implementing the actual bug-track system,
working over E-mail, and a set of CGI scripts from CERN implementing
the UI for the WWW. The fact that it is GNU is nice, it hooks into
EMACS, and the E-mail base allows it work with off-line or semi-off
line stuff. Jasper (our sysadm) can give you the setup we are using
(jasper.tredgold@bris.ac.uk)

> 
>  > I think at alpha level incompatable API changes are fine.
> 
> I would tend to agree, after all that's why Jigsaw has remained in
> beta for all this year.

Beta ? Have I missed something ?

> 
>  > Can you change my E-mail address to joel@asmodeus.demon.co.uk for the
>  > list ? Ta.
> 
> Done (hopefully, let me know if it didn't work)

OK thanks.

> 
>  > Did you resolve the issues relating to the lookup methods eating URL
>  > fragments ?
> 
> No, I am still looking for a spec, and won't have time to get into
> that until some days. Any propoosal ?

Hmm. First, I think that we need a proper idea of the functionality. It
seems so far that we have a confusing situation of Lookup, Lookup
Store and other lookup methods which are overloaded. Off the top of my
head....some insane burbling....

Assumptions: 
A1) ContainerInterface is implemented by all resources which can lookup
A2) ContainerInterface.lookup is a simple map of a single (defined char
    set and max length) input string to either null or a contained
    object.
A3) Lookup stops when the object refuses to implement ContainerInterface

I also suggest that :
S0) Idea of a LookupState is useful.
S1) Lookup takes a java.net.URL (or String ? they seem to be very
    easily confused), and is flexible enough to lookup anything. It
    returns a LookupState not a Resource, and the lookup state has tags
    such as isRemote, isLocal, isVirtualLocal, hasQuery etc. This could
    also have a tag isTerminal indicating that a leaf resource has been
    found, and isValid if a resource has been found.
S2) Any lookup should be non-destructive
S3) Lookups should be capable of cascading down through containers
S4) Lookups should be capable of backing up any number of levels.
S5) We should clearly define a) What characters are valid in a resource
    identifier (URL encoded ?), b) how long resource identifier should
    be.
S6) Lookup only happens once, all state is then passed around with
    either Request or Reply so that we don't get consistency problems.
S7) Lookup result and Lookup state become the same thing
S8) [ Query processing becomes a LookupState thing ? ]
S9) Resource lookup should be easy from within the server (so resources
    can lookup each other)
S10) For debug, lookup state should be able to log to a file the path
     it took to find each resource.
   
Elements of a lookup state:

E1) Protocol ?
E2) Host
E3) Port
E4) Full Path ( URL Encoded ? )
E5) Path section current (decoded?)
E6) [ Path section stack ? Holds decoded(?) path sections ]
E6) [ Query Vector - should this go in Request ? How do we handle
    repeated tags ? Merge or hold multiple ? (my preference hold
    multiple att-value pairs as that is best for my database stuff) ]
E7) Flags set containing : isValidURL (syntactically) isRemote
    isTerminal, hasQuery, isResource, isContainer (NOT isDirectory!),
    isVirtual, isLocal
E8) [ Resource section stack giving all resources in path ? ]
    
Questions: 

Q1) How do we handle POST, GET and POST with alternative forms of
    encoding (i.e. form-encoded[mime] not url-encoded)
Q2) How do we handle content negotiation ? Does this happen on
    containers as well as leaf resources ?
Q3) When do filters run ?
Q4) What happens when a URL encoded resource is encoded ? is it an
    identity transformation ?
Q5) Do we need special handling for a) serverlets, b) PATH_INFO cgi
    variables ?
Q6) Do we unravel via Exception or null return on a miss ? (My
    preference : null return to allow us to try multiple strategies and
    'cos exception are too slow)
> 
>  > Enjoy WWW6. Brian Kelly, UK WWW Academic Focus will be there looking
>  > for you...
> 
> Cool !
> Thanks,
> Anselm.
> btw: still hadn't had time to check your latest GlossaryFilter

Glossary filter would benefit from not having to re-parse the query -
is there some way to just retrieve the query from the Request or Reply
? If not, should filters have the lookup state passed though ?

Hope this is of some use.

Joel
-- 
Joel.Crisp@bris.ac.uk | ets-webmaster@bris.ac.uk  | "I remember Babylon" -
Software Engineer, Institute for Learning and     |        Arthur C Clarke
Research Technology, University of Bristol, UK    |
http://www.ets.bris.ac.uk/                        |

Received on Thursday, 27 March 1997 06:31:39 UTC