You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by Remy Maucherat <re...@apache.org> on 2000/06/28 20:14:31 UTC

Slide 0.9 features and timeframe

Hi,

I'm planning to release a first packaged version of Slide in the near
future. Version number will be 0.9 (beta status), and it will include
whatever libraries are needed to make it possible to unzip it and run it
without having to configure or download anything else.
I'd like to get some feedback and suggestions from people on that list.

- Timeframe is 2-3 weeks from now
- It will include the DAV client library and an administration command line
tool (which will make use of the DAV client library to communicate with the
Slide server)
- All DAV level 2 compliance issues should be resolved by then (most of them
deal with locking and PROPPATCH support, see STATUS.html for more details)
- Bugfixes

I'd like the DAV client library to be as complete as possible by then.
Right now, it can generate all of the DAV requests (except locking related
ones), but it doesn't parse the responses yet.

Remy


Re: Slide 0.9 features and timeframe

Posted by Remy Maucherat <re...@apache.org>.
> I would place documentation as the highest priority.  A detailed
description
> of the architecture is required.  The code also needs extensive
> documentation;
> running javadoc reveals little that can't be ascertained from the class
> and method names.

Ok, I'll add that on my list. I'll update the current documentation and try
to improve the helpers' Javadoc.

> I would agree that you need to be able to install and run a demo version
> without additional configuration.  Personally, I would favour a
> DescriptorsStore that is based around a file system, similar to IBM's
DAV4J.
> (The DAV4J javadoc coupled with it's simple interfaces, make it much
easier
> to understand than slide).

The DescriptorsStore handle the storage of every object in Slide (tree
structure, locks, ACEs, revision trees, ...), so that's probably why it's
quite complex.
For efficiency and time constraint reasons, I have not done a filesystem
implementation of DescriptorsStore yet, but it's certainly doable. In the
future, the goal is to be able to wrap existing versioning repositories,
like CVS.

> I would not place a high priority on the client, as dav_explorer allows a
> degree of experimentation.

It's highly insufficient IMO. That's one of the reasons why Proppatch is
still not supported.
I also think an administration tool (which would provide ACL and user
management, among other things) is needed. Besides, it's only a few days
work, and I have permission to work on that during work hours.

> It is essential however, that it works with
> web folders.  My vote would be to start looking at expanding WebDAV to
> support versioning and DASL - the specs look pretty complete.

I'll add DAV ACL as the top priority, IMO, so that the aformentioned admin
tool can also change ACEs on the namespaces. DAV ACL is really easy to
support, since most operations are done using PROPFIND/PROPPATCH.

> From my perspective it is the WebDAV servlet and supporting infrastructure
> that is most important, Not the application that it wraps.

> Incidentally, if you have any design notes, it would be worthwhile posting
> them with the source code, particularly those covering security.

Some basic documentation is included in directory docs/doc. I will try to
expand it (and also make it look nicer).
The Slide guide http://www.interlog.com/~bcholmes/geek/slide-home.html is
also a really good read.

Remy


Ant

Posted by Remy Maucherat <re...@apache.org>.
Hi,

I just updated the build.xml file, and it now uses the new "style" Ant
taskdef to build the HTML documentation, which is quite convinient.
Unfortunately, you now need to update to the latest Ant (from CVS) to be
able to use the Slide buildfile.

If you don't want to update, you need to remove those two lines in build.xml
(lines 110-111) :
    <style basedir="src/doc" destdir="${slide.build}/doc"
     extension=".html" style="style/slide.xsl" includes="*.xml" />

I had problems building the documentation using Xalan, so XSL:P should be
used instead. The pre-built HTML files are still present in the CVS
repositories (directory docs/doc), and I'll only remove them once those
issues with Xalan are resolved.

Remy


Ant

Posted by Remy Maucherat <re...@apache.org>.
Hi,

I just updated the build.xml file, and it now uses the new "style" Ant
taskdef to build the HTML documentation, which is quite convinient.
Unfortunately, you now need to update to the latest Ant (from CVS) to be
able to use the Slide buildfile.

If you don't want to update, you need to remove those two lines in build.xml
(lines 110-111) :
    <style basedir="src/doc" destdir="${slide.build}/doc"
     extension=".html" style="style/slide.xsl" includes="*.xml" />

I had problems building the documentation using Xalan, so XSL:P should be
used instead. The pre-built HTML files are still present in the CVS
repositories (directory docs/doc), and I'll only remove them once those
issues with Xalan are resolved.

Remy


Re: Slide 0.9 features and timeframe

Posted by Remy Maucherat <re...@apache.org>.
> Robert Mertens wrote:
> >
> > I would place documentation as the highest priority.  A detailed
description
> > of the architecture is required.  The code also needs extensive
> > documentation;
>
>      I agree.  I think that good documentation will do wonders for
> slide.
>
> > I would agree that you need to be able to install and run a demo version
> > without additional configuration.  Personally, I would favour a
> > DescriptorsStore that is based around a file system, similar to IBM's
DAV4J.
> > (The DAV4J javadoc coupled with it's simple interfaces, make it much
easier
> > to understand than slide).
>
>      <cough>  Okay, but "easier" != "easy".  And some of the
> documentation contained gross errors.  DAV4J did very little to shield
> you from having to understand the complexities of the DAV protocol
> (I'm no longer much of a DAV4J fan).

I just want to point out that DAV4J documentation is huge, and that I'm
mostly working on Slide on my spare time (except for the client). So bear
with me if a 100 pages documentation doesn't materialize overnight ;-)

The updated list of features for 0.9 is :
- All DAV level 2 compliance issues should be resolved by then (most of them
deal with locking and PROPPATCH support, see STATUS.html for more details)
- Documentation and JavaDoc updates
- Bugfixes
- Include whatever is ready for the administration client (no longer a top
priority; all that is needed to test propatch is already in)

> > Incidentally, if you have any design notes, it would be worthwhile
posting
> > them with the source code, particularly those covering security.
>
>      There are some documents in the slide workspace.  A bit too
> densely-written for my taste, but a good start.

And I still need to update the stylesheet ...
BTW, I'll modify the build.xml file and make use of the new style taskdef to
build the HTML documentation, so you'll have to update to the latest Ant.
Sorry for the inconvenience.

Remy


Re: Slide 0.9 features and timeframe

Posted by "B.C. Holmes" <bc...@interlog.com>.
Robert Mertens wrote:
> 
> I would place documentation as the highest priority.  A detailed description
> of the architecture is required.  The code also needs extensive
> documentation;

     I agree.  I think that good documentation will do wonders for
slide.

> I would agree that you need to be able to install and run a demo version
> without additional configuration.  Personally, I would favour a
> DescriptorsStore that is based around a file system, similar to IBM's DAV4J.
> (The DAV4J javadoc coupled with it's simple interfaces, make it much easier
> to understand than slide).

     <cough>  Okay, but "easier" != "easy".  And some of the
documentation contained gross errors.  DAV4J did very little to shield
you from having to understand the complexities of the DAV protocol
(I'm no longer much of a DAV4J fan).
 
> Incidentally, if you have any design notes, it would be worthwhile posting
> them with the source code, particularly those covering security.

     There are some documents in the slide workspace.  A bit too
densely-written for my taste, but a good start.

BCing you
-- 
B.C. Holmes         \u2625         http://www.interlog.com/~bcholmes/
"You know how deep some things are, and it's just impossible to get
 them out?  It all gets jumbled up inside.  Love, hate, nightmares...
 dreams.  Then you meet somebody you think will understand, but you
 don't know what to say.  Then you're afraid to say anything."
            - _Strangers in Paradise_

RE: Slide 0.9 features and timeframe

Posted by Robert Mertens <rm...@ptc.com>.
I would place documentation as the highest priority.  A detailed description
of the architecture is required.  The code also needs extensive
documentation;
running javadoc reveals little that can't be ascertained from the class
and method names.

I would agree that you need to be able to install and run a demo version
without additional configuration.  Personally, I would favour a
DescriptorsStore that is based around a file system, similar to IBM's DAV4J.
(The DAV4J javadoc coupled with it's simple interfaces, make it much easier
to understand than slide).

I would not place a high priority on the client, as dav_explorer allows a
degree of experimentation.  It is essential however, that it works with
web folders.  My vote would be to start looking at expanding WebDAV to
support versioning and DASL - the specs look pretty complete.