Hi, >If the task is "define a patch format for use over HTTP Patch", then >yes, we can assume HTTP is there.
Yes. But for Jackrabbit 3, we want to define an API that doesn't require HTTP (or ZIP). Currently it's a Java API, but we might extend it to other programming languages such a PHP, C#, and C. >We still suffer from an agreed-upon set of design goals and constraints. In my view, the goal is to standardize a format that supports the features required by the current use cases. Probably the most advanced use case is the Jackrabbit 3 MicroKernel API. Also, the features required by the MicroKernel API should be supported. The format can't rely on a HTTP binding. >If we want to *standardize* something, we need to abstract away things >specific to JCR. The standard must not refer to JCR, but the standard should support the features required by JCR. Is this what you mean if you write "abstract away"? > Also, we need either to get the features we need into >the common formats (such as support for tagging batches or adding >tests), *or* need to make sure extension points are in place. I agree. Extension points could be documented as optional features. Regards, Thomas
