<?xml version="1.0" encoding="utf-8" ?>
<propertyupdate xmlns='DAV:'>
<set>
<prop>
<high-unicode xmlns='http://webdav.org/neon/litmus/'>𐀀</high-unicode>
</prop>
</set>
</propertyupdate>
[Note that I reformatted the output, so the content-length is broken]
Now: whose problem is this Slide's or JDOM's?
Java's? Java doesn't tend to cope too well (at least not without significant extra effort by the programmer) with stuff outside the BMP. It's probably some sort of bug in JDOM, technically - but I'm not sure about that. It'd be painful to fix.
- o -
Now a few random questions:
1) what's the status of the tree? I found out that contributed WebDAVGUI is out of synch with the various libraries and it seems dead. I also find the distribution waaaaay too tomcat centric.
The slide core is reasonably stable and well tested. Likewise the slide webdav server frontend. Everything outside of that is in various states of disrepair. The distribution might be mildly tomcat-centric, the code is not - and since users aren't going to be able to use the distribution as-is anyway, I don't think this is a major problem.
2) I saw the archives and I heard about the 2.0 release proposal, what's the status of that?
Under discussion. Looks likely to happen in the next few months.
3) also, what's the status of the variuos stores? are they usable?
No. They all have either critical correctness or performance problems. Work is happening to provide a usable JDBC-based store in the relatively near future.
4) now a more detailed question: does the DASL implementation provided with Slide scale? are the content metadata stored in the DB or are stored along with the files?
The DASL implementation with the available stores is extremely non-scalable. Content metadata is stored in the DB if you're using a DB-based store, as are the file contents.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
