Subject: [LON-CAPA-dev] lonc/lond, construction space, etc

From: Gerd Kortemeyer <[email-masked]>
Date: Sun, 26 Jan 2003 21:29:33 -0500

[Moved from users to dev]

Hi,

Guy Albertelli II wrote:

> > Ron Fox wrote:

> > >   The export problem is perhaps a specific instance of a more
> general
> > >  problem that could be solved: Allow access to construction space
> > >  from any server, not just the home login server.
> >
> > That would be extremely cool!
>
> I think I would argue against this.

My  two cents would be that only the web interface of the constuction
space is going to work cross-server, while the construction space
continues to resides on one and only one server. If the author wants to
sftp, mount, samba, or appleshare the disk (direct access), they still
have to connect to their home server.

I agree with Guy, trying to distribute sftp and other direct access
methods would create all of the horrible mess he describes. When doing
direct access, however, it would be great if the permissions and
ownership could somehow be figured out. Users continue to mess up the
permissions ... not sure how this can be solved, it is hard ...

In summary: lonc/lond would be the file transport layer for the web
interface only.

BTW, what is all this WebDAV business (besides creating weird error
messages on our servers)? I am currently in New Orleans at the Educause
NLII Conference and actually just registered for their "Next Generation
Course Management System" Focus group in Tuscon, AZ, on March 7th
(anybody wants to come along?). Anyway, on the "wishlist" for the "Next
Generations CMS" is WebDAV authoring support - can we do that against
our construction space?

Next thing is that in the lonc/lond rewrite we probably should look at
the OKI stuff right from the start, so that at least we do not do
anything to keep it from working. Check out http://web.mit.edu/oki/ and
in particular http://www.lon-capa.org/oki.html, which is the outcome of
a technical discussion with the folks over there. Note that OKI lives
both above and below lonc/lond, which all of us found a clean solution
to get around the problem that OKI has no concept whatsoever of a
multi-server peer-to-peer network. For us, that means we need no
revolution to do OKI, but should keep it in the back of our heads as we
write our stuff.

... well, this was probably more than two cents. Of course, in all of
these revolutions, we need to make very sure that we have a very very
stable production environment in Fall 2003, which probably means that a
lot (if not all) of the stuff above simply has to wait. In talking with
the other MSU folks who are here in New Orleans the biggest issue they
have against LON-CAPA is bugs, meaning, they doubt that it can serve all
of MSU because it is not a production but a research system - we need to
remove that obstacle and perception. Bugs are the number one reason that
we are having problems gathering central support. So: let's put all of
these cool features on the back burner, unless we can be very very sure
that they work and do not destroy other functionality.

- Gerd.

---

From: Jerf <[email-masked]>
Date: Sun, 26 Jan 2003 19:35:57 -0500

Gerd Kortemeyer wrote:
| BTW, what is all this WebDAV business (besides creating weird error
| messages on our servers)? ...
| Next thing is that in the lonc/lond rewrite...

WebDAV is Web Distributed Authoring and Versioning. See
http://www.webdav.org/other/faq.html for the various features.

I don't know when lonc/lond The Rewrite is scheduled to be out, but if
it's post-Fall 2003, one idea worth researching is having the authoring
space be manipulated solely through WebDAV, since it seems to match with
our ideas fairly well. (I say post-Fall 2003 because this definately
qualifies as a big change, falling out of the scope of bug fixing.)

The benefits of this approach is that a single interface meets both our
internal needs and external user's needs in a standards compliant
manner, and since this *is* a standard there are libraries we can lean
on both the server and client side, which could really simplify a huge
portion of the authoring space stuff. For instance, there is already a
well-tested Apache webDAV module: http://www.webdav.org/mod_dav/ .
Whether or not it is useful would take more research. Perl clients:
http://search.cpan.org/search?query=webdav&mode=all .

The downside is that WebDAV could be either too powerful (such that a
partial implementation gets us nothing because all real-world WebDAV
clients demand Fancy Feature #2, and we can't implement it for some
reason, so the standards compliance is no benefit), or possibly not
powerful enough (though in that case we could do some internal
extensions). Also, this would take some research, though if WebDAV is a
fit it may pay off in terms of bringing in well-tested existing WebDAV
libraries rather then re-inventing it ourselves again.

I can say with confidence that the WebDAV stuff is not going to go away.
It's RFC 2518: http://andrew2.andrew.cmu.edu/rfc/rfc2518.html . It's
reasonably widely deployed in certain communities, and it seems to me to
be on a growth pattern, not a niche-player-forever pattern.

---

From: Gerd Kortemeyer <[email-masked]>
Date: Mon, 27 Jan 2003 14:56:47 -0500

Jeremy,

Thank you for all of the background on WebDAV, supporting it certainly
looks intriguing. Making WebDAV the only way to access construction space
will probably not work, though. Experience shows that expecting faculty to
have any functioning piece of software on their computer besides a web
browser ends up being a headache - CAPA has a lot of experience with
X-clients even from the time when we had only "power-users" ... I think we
always need to support the simple web browser interface.

- Gerd.

Jerf wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gerd Kortemeyer wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE+NH7sPaYWE58at8cRAorGAKCbEnij/clHeOeZsJMSIy5KhkIR5wCfbYez
> x2NqaxCRimZ5vhLMAP4EauI=
> =3sVU
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> LON-CAPA-dev mailing list
> [email-masked]
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-dev

---

From: Gerd Kortemeyer <[email-masked]>
Date: Mon, 27 Jan 2003 15:01:51 -0500

Jeremy,

- Gerd.

---

From: Jerf <[email-masked]>
Date: Mon, 27 Jan 2003 11:18:07 -0500

Gerd Kortemeyer wrote:
| Jeremy,
|
| Thank you for all of the background on WebDAV, supporting it certainly
| looks intriguing. Making WebDAV the only way to access construction space
| will probably not work, though. Experience shows that expecting faculty to
| have any functioning piece of software on their computer besides a web
| browser ends up being a headache - CAPA has a lot of experience with
| X-clients even from the time when we had only "power-users" ... I think we
| always need to support the simple web browser interface.

Sorry, I was unclear. What I meant is instead of having something in the
internals of LON-CAPA manipulating the author space, and writing
seperate external access methods, implement WebDAV and then have the
internal methods just be WebDAV client calls.

AFAIK, that doesn't preclude completely independent access methods like
Samba mounting; the idea is to reduce the ugly file-twiddling code in
LON-CAPA and ship that off to somebody else's well-tested libraries, not
eliminate features. ;-) The current web interface would still work, and
it should even call the same functions for manipulation it does now,
it's just those functions could be implemented in terms of WebDAV
instead of direct file manipulations. (Ideally, the web interface is
seperated enough that it would be totally unaffected by any such change
to the underlying file access methods, be it a radical change to WebDAV
or even a simple restructuring of file access modules.)

Again, let me emphasize I don't know that this would work perfectly and
it would take some research into it, but it could pay off by making us
write one less nasty part and getting a standards-compliant access point
"for free".