Re:future plans...

This is cool!

Some small things that should be easy to do, but might be usefull:
1) Might be nice, if more resources would use title Attribute for usefull
things. Eg. DirectoryResource could give a title, if available, instead of
boring 'Directory of Bla'. I think  it would be nice to have that, not sure
if anybody else supports it. :-?

2). Default HEAD implementation does GET and then cutoff the entity body.
It might be more efficient if at least the major resource like FileResource
and DirectoryResource override that to do faster version of HEAD. That
might give a slightly better edge.

3) extended() method default handler,  gives and error of unimplemented
UNLINK method. Just cut and paste problem, I guess. :-}.

4) Documentation seems to be inconsistant. Somebody should really look into
it. (mostly URL references and some CLASSPATHs, but some things like "The
only real way to reindex the whole system is to delete all .jigidx files
and let Jigsaw to reindex everything when it needs it." - here goes all the
admin functions, they are not recreatable. Remember somebody was saying
that bootstraping Jigsaw was a tricky bit :-} ).

5) URL to <http://www.w3.org/members/WWW/Jigsaw> should be either removed
from sample welcome Jigsaw page or open for public. It gives 403 Forbidden
by Rule everytime, and Boy I would like to know what is supposed to be
behind those closed doors. :-}

Good luck,
     Alex.

Ps. Just a note: Jigsaw Alpha 1 is cleaner then some products' gold
versions....... :-}


At 9:06 PM on 23/6/96, Anselm Baird-Smith wrote:

> I think it is time to tell you about Jigsaaw futur plan. For the time
> being, as I said several time, I will concentrate on turning Jigsaw
> first into HTTP/1.1 compliancy , then into a caching proxy. More
> preciselyt:
>
> a) Rewrite all the w3c.mime package, for more efficiency
> b) rewrite the Request/Reply class to make use of the new Mime parser,
> and to fix some of the problems that have been mentioned here
> (Request/Reply deficiencies).
>
> These two changes should be invisible from the high level APIs, I hope
> to be able to do them and still leave the Request Reply APIs unchanged
> (there may be some minor tweaks, but not too much).
>
> c) Write the caching proxy stuff, this will have no impact on the
> APIs, and hopefully (again !)  Jigsaw should be the first 1.1 caching
> proxy :-)
>
> d) Fix a number of deficiencies in current APIs:
>
> d1) Most of the feedback I got from this list (thanks to you) should
> be incorporated in next release, this includes things like the extend
> flag of directory resource also serving as a shrinking indicator,
> etc. At this point this is the precise list of things:
>
>     FileResource should delete themselves when the underlying file (in
>     the filesystem) &nbsp;is erased <I>and</I> the extensible flag is
>     set.
>
>     ResourceStoreManager should be able to save/load&nbsp;.jigidx from
>     some other directory.
>
>     User name resolution through a speical UserDirectoryResource.
>
>     The <I>.jigidx</I> default value for the DirectoryResource storeid
>     attribute should be a property.
>
>     "Couldn't parse request" and "Resource temp unavailable" should
>     not be displayed in the errlog file.
>
>     Deleting a directory resource should also delete the associated
>     resource store
>
>     The extensible flag should also control "contraction" of the
>     directory (non existing files).
>
>     Deleting auth realms doesn't work.
>
>     w3c.jigsaw.forms.FormCardHandler:notifyEndProcessing should be
>     able to return back a full Reply, rather then only a simple
>     redirection.
>
>     Virtual host handling
>
>     [If you do thing I have missed some items, let me know]
>
> d2) Fix the .jigidx file format. This one is the one that will hurt
> Jigsw's users. The poblem with the current .jigidx fie format is that
> it doesn't allow for extensions: it you change the attribute list of a
> resource, you have to erase the whole .jigidx file. The next format
> should allow for better upgrading scheme, typically by using a less
> efficient property-like format (attr=value).
>
> In the mean-time applet based configuration is being worked on, along
> with various new resources (we already have, for example, a
> MapFileResource to handle server-side image maps, and server side
> include should also be worked on). A sample implementation of PEP
> (Protocol Extension Protocol) will also be worked on as a filter.
>
> Now, when will this new release of Jigsaw will be out ? My hope is to
> get it out by the end of August, and it will be Jigsaw1.0a2, or
> Jigsaw1.0beta depending on how comfident we are...both in Jigsaw and
> in the underlying Java implementations ;-)
>
> Anselm.

alex@access.com.au

Received on Sunday, 23 June 1996 21:38:46 UTC