hi all
with the fix in Revision: 1466554 in place the build passed
on my instance that includes the 'real' permission evaluation.
therefore i decided to throw away that tmp solution in order
to get the remaining issues sorted out (treelocation, how
to implement the commit...): revision 1466562.
hi jukka
Calculate the readState directly when a SecureNodeState is instantiated
(may need to make it lazy again later, TBD) so we can add the getChildNode()
optimization where we return a fully readable leaf node state directly
without a SecureNodeState wrapper.
i am not convinced this is a
hi jukka
On Tue, Apr 9, 2013 at 12:45 PM, Angela Schreiberanch...@adobe.com wrote:
i am not convinced this is a wise move. as i keep stating we used
to have short lived sessions that rather perform random access to the
repository instead of reading the complete ancestor tree. calculating
the
with keeping it longer. But we should definitely remove it from oak-core
before we go 1.0. Maybe we should open an issue with the an 1.0 target
so we don't forget.
Michael
On 4.4.13 18:25, Angela Schreiber wrote:
hi
there is still quite some code left that is has old
in it's package name
looks reasonable to me... that would also allow to write better
commit hook tests that don't mix up the different type of failures
and just pass by coincidence.
angela
On 4/5/13 1:27 PM, Jukka Zitting wrote:
Hi,
I'd like to introduce error codes for the CommitFailedExceptions
thrown by
hi ian
One last question.
Should I expect a a SecurityConfiguration to be present ?
no, you have to specify the security provider you want to
use. this is still work in progress but right now SecurityProvider
was the entry point to use. there is also a known TODO in the
Oak class because the
hi
while taking a closer look at the base state associated with a TreeImpl
i got the impression at the same base NodeState is also available from
the NodeBuilder associated with the tree.
if this was really the case: what is the reason for keeping it twice?
regards
angela
as long it has not been disconneted and
throw IllegalStateException otherwise to avoid odd behavior.
angela
On 4/2/13 12:46 PM, Michael Dürig wrote:
On 28.3.13 15:19, Angela Schreiber wrote:
hi michael
With the resolution of OAK-690, I made tree instances stable across save
and refresh operations
hi jukka
sure... you may want to look at the items accessed for a
regular cq page request in order to come up with a realistic
scenario and then scale that up to a huge repository.
however, please keep in mind that if we are really going to move
the permission evaluation below the tree level, we
hi bart
Well that reduces the question to just *how* to do it ;-)
sure...
I was just jumping in because we experienced many problems with this
use case with JR2 and was wondering if it's was worth the effort to
support it.
right... but there is no much use for us in creating a default
hi jukka
i like the idea of having read permission enforced on the node state
level and avoid the null checks as it is a similar approach we
are currently having by the treelocation concept that michael introduced
some time ago.
the only thing i keep struggling with is: i don't want to evaluate
hi marcel
On 3/19/13 4:09 PM, Marcel Reutegger wrote:
right... but i don't see why we have to recalculate the path
when the node states already know about them and we usually
do know the path of an immutable tree because we have
traversed to there using the TreeLocations.
the problem is, only
sorry... will fix it right away.
On 3/12/13 10:07 AM, build...@apache.org wrote:
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/1791
Buildbot URL: http://ci.apache.org/
hi jukka
I'm not implying that the suggested solution in OAK-660 is wrong
(apologies if that was how I sounded)
ack
, just trying to understand why it was chosen
it's not yet chosen... its work in progress and am still in the
very first iteration (compared to us having up to 5 different
-1 from my side. i think it's important to distinguish protected
items that are meant to be filled in by the system or by dedicated API.
if the evaluation is slow we should optimize it.
kind regards
angela
On 2/25/13 2:17 PM, Jukka Zitting wrote:
Hi,
While doing some basic benchmarking of
i am not totally sure if the checkProtection can be delayed until
the save call. the specification states:
If an item I is declared protected it is repository-controlled.
If I is a node then, through the core write methods of JCR (see
§10.2 Core Write Methods),
• I cannot be removed,
• child
hi jukka
honestly, i fail to see the duplication apart from the fact the
there is a certain structure and flow of control given by the
java LoginModule base class.
the authentication in jackrabbit core was heavily depending on
jackrabbit core internals while the rewrite in oak doesn't make
use
hi jukka
now that you have committed an initial patch for OAK-627 (thanks)
i will check if there wasn't a smarter solution for OAK-625...
update will follow in the issue.
gruss
angela
On 2/15/13 1:48 PM, Jukka Zitting wrote:
Hi,
On Thu, Feb 14, 2013 at 7:38 PM, Angela
hi
I'm wondering if we could promote the #setHook method to the NodeStore api?
The intention so far has been to keep NodeStore functionally
equivalent to the MicroKernel, i.e. just a higher-level wrapper that
hides details like caching, JSOP processing and revision/path
tracking. Adding
see https://issues.apache.org/jira/browse/OAK-627
On 2/14/13 6:38 PM, Angela Schreiber wrote:
hi
I'm wondering if we could promote the #setHook method to the NodeStore api?
The intention so far has been to keep NodeStore functionally
equivalent to the MicroKernel, i.e. just a higher-level
hi michael
ok... but the subject of this thread is the behavior of nodes
upon move and as a simple test shows the behavior is the same
for both referenceable and non-referenceable nodes.
while i agree that the behavior of same nodes may change
due to the way we define the identifier, i would
sound good... the rest was probably a misunderstanding :-)
gruss
angela
On 2/8/13 10:39 AM, Michael Dürig wrote:
On 8.2.13 9:10, Angela Schreiber wrote:
hi michael
ok... but the subject of this thread is the behavior of nodes
upon move and as a simple test shows the behavior is the same
sorry for that... will fix...
On 2/7/13 11:33 AM, build...@apache.org wrote:
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/1492
Buildbot URL: http://ci.apache.org/
in addition we still have an open TODO that the identifier
of a non-referenceable node should be as stable as possible
which means that it should include the identifier of the
parent... in other words: if one of the parent was referenceable
the identifier should be somehow combine uuid + relative
as far as i remember we never decided to use the path as
identifier. we said that we want to keep it as stable as
possible... for a referenceable node Node#getIdentifier
returns the UUID for a non-referenceable node it should
include the parent identifier and a relative path thing.
kind regards
hi
in order to address OAK-444 without excessive uuid resolution
upon access control evaluation i create a separate commit hook
that keeps track of the path of versionable nodes .
since the version information is defined to be 'global' for a
given respository while the versionable path might
hi michael
passing in a default parameter for method that returns boolean
looks pretty awkward to me and i somewhat dislike the lengthy
names because the of the utility was to make the code readable.
but i will add some javadoc both in TreeUtil and in NodeUtil.
angela
On 2/6/13 11:28 AM,
things as well (e.g. OAK-453).
I suggest we schedule a session for that at next week's Oakathon in
Basel. WDYT?
Michael
On 6.2.13 9:57, Angela Schreiber wrote:
hi
in order to address OAK-444 without excessive uuid resolution
upon access control evaluation i create a separate commit hook
hi jukka
I would simply use UUID lookups for that. [...]
that doesn't work because we have to deal with lost
content in the version store i.e. version histories
whose versionable node has been removed... basically
that's the fundamental problem behind the various issues
we are facing with
hi jukka
Wouldn't any other version history - path in workspace mapping face
the same problem?
no.
From the top of my head I'd treat such lost version histories as
admin-only content until someone re-connects them by cloning a
versionable node from another workspace or importing one from
hi jukka
i just learned that this discussion wasn't solely about the Tree's
behavior upon move/rename but also affects the JCR Nodes.
as stated in https://issues.apache.org/jira/browse/OAK-606
and https://issues.apache.org/jira/browse/OAK-607
the current behavior is IMO inconsistent between new
hi michael
thanks for the information. i agree that 3) currently seems the
way to go if we want to address the move issue.
from my experience move operations are rather rare (as already
noticed by jukka). in combination with the fact that our main use
case in general involves very shorted-lived
hi michael
while looking at the TreeLocation implementation was wondering about
NullLocation#getParent() as IMO it violates the API contract because
it always returns the NULL-location. is there a particular reason
for this? and wouldn't it be possible to return the original
parent location
missing something?
regards
angela
On 1/31/13 2:33 PM, Michael Dürig wrote:
On 31.1.13 13:08, Angela Schreiber wrote:
hi michael
while looking at the TreeLocation implementation was wondering about
NullLocation#getParent() as IMO it violates the API contract because
it always returns the NULL
hi devs
i recently came across quite some new oak code that has
already been marked deprecated... for example the old
index implementations.
would it be possible to get rid of those deprecated classes
and methods? since OAK is a completely new repository
implementation i don't see why we should
hi devs
i start getting blocked by OAK-396 [0] as it prevents me from
writing any access control content in a real-life test setup that
has query index.
quickly applied the patch proposed by alex but it seems to me
that there has been made quite some progress in the index code
base such that
hi alex
All tests pass but everything extending AbstractSecurityTest doesn't use any
kind of indexes for the tests.
I would have liked to add the p2 ones (Property2IndexHookProvider,
Property2IndexProvider) to the tests but then some of them start failing (the
ExternalLoginModuleTest and
that test keeps failing in my checkout every now and then...
i couldn't detect a useful pattern though, that allowed to explain
the failure.
regards
angela
On 1/22/13 1:59 PM, Michael Dürig wrote:
Tests in error:
testConcurrentGC(org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest):
should be fixed again
angela
On 1/11/13 5:05 PM, build...@apache.org wrote:
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/1310
Buildbot URL: http://ci.apache.org/
the corresponding jira container issue is
https://issues.apache.org/jira/browse/OAK-458
feel free to append ideas, patch there or create subtasks
regards
angela
On 1/9/13 8:33 AM, Thomas Mueller wrote:
Hi,
For migration options see
http://wiki.apache.org/jackrabbit/BackupAndMigration
There
sorry. forgot to commit code to jackrabbit-jcr-commons.
will do that in a moment.
angela
On 1/9/13 5:58 PM, build...@apache.org wrote:
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
thanks a lot!
On 12/14/12 7:47 AM, Jukka Zitting wrote:
Hi,
On Thu, Dec 13, 2012 at 9:00 PM, Angela Schreiberanch...@adobe.com wrote:
from time to time the build fails during test
execution in oak-it-osgi:
Fixed in revision 1421690. There was an accidental use of
hi
from time to time the build fails during test
execution in oak-it-osgi:
Tests in error:
testOakRepository:OSGiIT.testOakRepository:NativeContainer:org.apache.felix.framework.FrameworkFactory@6719dc16(org.apache.jackrabbit.oak.osgi.OSGiIT):
org.apache.jackrabbit.oak.api.ContentRepository
hi michael
i would really appreciate if you would not comment out test-cases
that i deliberately added, just because a half-way fix of
yours makes them fail.
so, -1 for the changes made in particular the following:
@@ -332,8 +334,8 @@ public class OakAuthorizablePropertyTest
@Test
hi tom
IMO that will not work for the case manfred is referring
to as it is operating on the oak-api and not on jcr api.
so -1 for that one.
kind regards
angela
On 11/27/12 3:22 PM, Thomas Mueller wrote:
Hi,
Currently it is planned to use the commit hook feature to update the
index. Is the
hi michael
+TreeLocation loc = getLocation();
+for (String element : PathUtils.elements(relPath)) {
+if (PathUtils.denotesParent(element)) {
+loc = loc.getParent();
+} else if (!PathUtils.denotesCurrent(element)) {
+loc =
hi jukka
if we decide that having long mv properties is a valid use-case
we should have support for that in the repository.
back in jackrabbit-core i remember just one case where this
limit actually was a problem: the group members stored in a
mv property... and michael at that time added to
The client is trying the following request:
http://localhost:8080/davex/default/jcr%3aroot/.0.json
I'm not sure why it's requesting a json file at all
it doesn't request a json file it requests the json serialization
of the root node in this case.
... , but the url doesn't seem to work with
sorry for that... i will take a look at it.
On 10/30/12 11:40 AM, build...@apache.org wrote:
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/896
Buildbot URL:
hi michael
+ * TODO review again if we really need/want to expose that in the OAK API
The consequences of not doing so is, that there is no way to create
blobs through the Oak API which are immediately streamed down to the
Microkernel.
yes... i know :)
don't get me wrong, i am not opposed
, Angela Schreiber wrote:
hi michael
thanks for the info
Note that createBlobd() is very much the same as the
getCoreValueFactory() method, which it replaced.
yes, i am aware of this... the reason why i don't like
the method on contentsession has nothing to do with the
'what-it-does' but rather
hi chetan
3. SecurityProvider - Need to register SecurityProviderImpl backed by
OSGi configuration with SR. Would it be fine now to add osgi related
changes
the security provider is IMO just a temporary solution
in order to have a quick way to setup the system. there will
for sure be major
hi all
recent the ContentSession interface got a new method
Blob createBlob(InputStream inputStream) throws IOException;
this there is no TODO comment associated with it i assume
that is intended to stay... however, it feels a bit odd to
me having that method on the content session interface
it wasn't
the responsibility of a contentsession to deal with binary
values when at the other hand we have all value handling
separated out to a ValueFactory(Impl).
kind regards
angela
Michael
On 19.10.12 8:54, Angela Schreiber wrote:
hi all
recent the ContentSession interface got a new method
i will take a look later today or tomorrow and will
take another look at the query-tests as well.
angela
On 10/17/12 4:11 PM, build...@apache.org wrote:
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
works on my machine... just takes (too) long.
angela
On 10/10/12 2:14 PM, build...@apache.org wrote:
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/733
Buildbot URL:
- Finally, there was quite a lot going on in the security area wrt.
access control, authentication support, principal management and so.
Angela, since you were mainly concerned with this, do you mind to give a
quick update on what's new here?
there is just one topic that IMO is worth
hi tommaso
At the same time I see the community development concern; I'm still quite new
here so I don't have a clear understanding of who is actually working on both
Oak and Jackrabbit and who's working only on one of them, also it may be that
this distinction doesn't actually exist at the
hi alex
based on the experience with jackrabbit i would suggest
to always use CoreValueFactory#create* and treat the
individual value classes as implementation detail of the
factory... this allows to change the implementation or
add improvements later on.
kind regards
angela
On 9/21/12 11:49
hi alex
the user management is not enabled so far as there are still
too many missing parts in oak... for example the weakreferences
and proper support for reference values.
in other words: right now it doesn't bother me if the query
conversion isn't completed as i can't run the tests anyway.
hi all
i was trying to get some minimal permission check enabled in
the current oak trunk and found that this causes a huge amount
of tests to fail.
reason: the tests use a guest-session expecting that that was
is granted all permissions, which isn't a realistic scenario.
the guest-session will
hi
the oak project is still in a fairly early stage, but you may
want to take a look at
some information about oak at
- http://jackrabbit.apache.org/oak/
- http://wiki.apache.org/jackrabbit/Jackrabbit%203
information regarding jcr:
- http://jcp.org/en/jsr/detail?id=283
-
hi michael
the implementation of Tree#remove starts with the following line:
if (!isRoot() parent.hasChild(name)) {
and it seems to me that testing for the parent containing the
Tree that i am having at hand is superfluous. is that the
leftover of a refactoring or could it really
just found that Tree#getStatus() never returns REMOVED (see OAK-207).
if that was the reason for that extra check i would suggest to
refactor the code and check for status removed... that felt much
clearer to me.
gruesse
angela
On 7/24/12 1:30 PM, Angela Schreiber wrote:
hi michael
hi jukka
i see your point regarding keeping the API as small as possible.
that's basically why i was asking for a list of those special
properties that we already know or envision to introduce.
was it possible for you to share the known set of special properties
with the team?
that would allow
hi jukka
was it possible for you to share the known set of special properties
with the team?
See the end of my message from yesterday.
oh, i see... i got that wrong since the original mail and the issue
gave me the impression that there already exists quite some internal
content.
if i
hi jukka
thanks for the info.
As you noticed, it's meant for use by plugins that want to access a
raw NodeState through the Tree API without any internal layers
(security, etc.) in between. Ideally such a wrapper wouldn't be
needed, as it mixes levels of abstraction, which is why I didn't want
hi jukka
makes a lot of sense to me and pretty matches the goal of he
whole JSOP approach.
there is just one thing i don't feel totally comfortable with:
By default the HTTP binding could simply use a fresh new session for
each HTTP request, but it should be possible for a client to request a
hi jukka
On 6/27/12 11:43 AM, Jukka Zitting wrote:
On Wed, Jun 27, 2012 at 8:27 AM, Angela Schreiberanch...@adobe.com wrote:
a) is it on purpose that the value constructors are public?
The value classes are package-private, which also limits the
visibility of the constructors. Having the
hi stefan
i thought that we have a consensus of how the oak stack should be layered, i.e.
that was my understanding as well
app / sling / oak-jcr (trans. space) / [remoting /] oak-core [remoting
/] oak-mk.
or alternatively:
app / non-java-content-repo-api / [remoting/] oak-core
hi julian
NodeTypeImpl#isNodeType which was comparing the jcr-name
exposed in getName() with the string passed to the call.
the latter can of course be an expanded name too such as
the one i used with the constant :-)
Yes, it's all a mess right now :-).
indeed. i would suggest that we stop
hi julian
indeed. i would suggest that we stop using hardcoded
strings and use the constants defined in the JCR API instead.
Absolutely. We just need to be careful with layering; as far as I
understand the expanded names will not work for Oak-Core APIs.
right... i was only referring to
hi
it seems to me that we currently lack all kind of support for
RangeIterator#getSize in various places such as Node#getNodes
and Node#getProperties in all different flavors.
while this might be perfectly reasonable in those cases where
an node has a huge amount of child items, i would argue
okathon?
was that a hidden proposal for renaming oak to oka?
according to jukka that's a finnish word (thorn)...
and it get's pretty close to okra which imo are
tastier, aren't they?
+1 ;)
hi jukka
I had a quick look at the current authentication configuration in
oak-core. Currently the ContentRepositoryImpl class simply creates a
LoginContextProviderImpl instance with a hardcoded configuration. As
said in the related TODO, we'll need to come up with an easy way to
specify custom
hi julian
1) missing Date-long/double/decimal value conversions. I have added
those for now in ValueImpl (not core); is this correct, Angela?
as long as we don't need it in the core, i would add it in oak-jcr.
we can still push i down to the CoreValue later on.
the basic question is again
hi all
felix created an issue asking for cleanup of the oak-core
module, specifically removing the o.a.j.mk packages [1].
is anybody working on this? or does anybody know what was the
status of that issue? can we remove those packages altogether or
are the parts that need to be moved to the
hi all
as a next step i will address the last major issue in this
area: encoding non-json property types before writing to
the MicroKernel (currently in KernelRoot#encode) and the
other way round (currently in KernelNodeState#readValue).
in a first step i will move both methods to a utility
quite some tests from TCK that deal with value-conversion etc.
kind regards
angela
[1] http://svn.apache.org/viewvc?rev=1329612view=rev
[2] http://svn.apache.org/viewvc?rev=1329741view=rev
On 4/23/12 5:41 PM, Angela Schreiber wrote:
hi all
as discussed recently in revision rev. 1329281 [1] i
hi
i would like to suggest that we rename ContentTree to Tree.
as the Content-prefix looks a bit artificial (and arbitrary) to
me. while i see the point in having the ability to distinguish
jcr-Session from oak-Session and jcr-Repository from oak-Repository,
i fail to see the benefit for the
hi all
as discussed recently in revision rev. 1329281 [1] i added a
new implementation of ValueFactory and Value/Binary in oak-jcr that
is based on value handling exposed by oak-api.
my goal was to address both the needs from jcr (API contract)
and oak-core (ability to detect value types for
The main open questions now revolve around workspaces and permissions.
well, there are actually no questions regarding permissions. it's
pretty clear what we want/have to do and where we need to do it.
the only question is if that's possible and sensible with the
whole-repo-exposure on
hi michael
just to make it short:
that's not sufficient IMO. if the content tree presents the
Node than it might simply be that you don't have access to it
due to access constraints that are are being enforced in oak-core.
Well the peculiarities of this is what I wanted to find out about in
hi michael
that's not sufficient IMO. if the content tree presents the
Node than it might simply be that you don't have access to it
due to access constraints that are are being enforced in oak-core.
Well the peculiarities of this is what I wanted to find out about in the
questions in my
hi michael
Ok, makes sense. We need then
- Have a respective value entity on the oak-api. There is already the
CoreValue class which should somehow fit/be fitted into the picture.
- Update all places in the API where Scalar is used currently with the
new value representation.
rather do it
hi
On a related note: what kind of values do we want to expose from oak-core?
JSON like or JCR like?
I'd ideally like to keep it JSON-like so we can easily implement a
JavaScript-friendly HTTP mapping directly based on the Oak API without
having to go through extra levels of mapping.
hi michael
having said that: thinking of a ValueFactory implementation
in oak-jcr that creates Value objects that can server both as
jcr-values and oak-values. the internal representation could
still be anything including json-representation... but we
wouldn't be limited to JSON types on the
hi
here the summary of some initial observations that i made while
looking at the oak-api today:
a) NodeState is never used in oak-jcr
as far as i saw the NodeState interface is never used in the
scope of oak-jcr in contrast to TransientNodeState that
is omnipresent.
basically i
to me.
kind regards
angela
On 4/13/12 5:20 PM, Michael Dürig wrote:
On 13.4.12 13:29, Angela Schreiber wrote:
here the summary of some initial observations that i made while
looking at the oak-api today:
Thanks for the review. Before I comment on the individual points let me
explain
hi michael
On 11.4.12 16:41, Angela Schreiber wrote:
hi
thinking about how to implement the various JCR level operations
that are beyond regular item modification, i found that IMO
will face at least the following 4 types of writing that would
from a oak-api point of view may just look like
hi michael
that looks really wrong to me. the way i think of the oak-api
is that i obtain the connection from oak-api upon Repository.login
and it would be used for the communication for the lifespan of the
JCR session obtained. retrieving another connection is definitely
not what i am looking
hi
On Wed, Apr 11, 2012 at 6:30 PM, Michael Dürigmdue...@apache.org wrote:
The current API should be able to cope with transient modifications and
non-transient modifications. The latter can be done by obtaining a new
connection just for those changes.
IMHO a separate connection shouldn't
hi jukka
On Tue, Apr 3, 2012 at 11:23 AM, Angela Schreiberanch...@adobe.com wrote:
but please be aware that we need to make sure that we need
to have a separate layer in place that enforces authorization
and prevents direct write operations on the MK from higher
levels... or the other way
hi jukka
Basically my idea is to have the namespace registry stored in some
system location (like /:system/ns) and accessed over the standard Oak
API.
imo it should be /jcr:system/jcr:namespaces.
we already have the same pattern for node types, versions,
configuration, activities with are on
hi jukka
The trouble with this is that it's *repository*-level information,
i.e. shared by all workspaces.
exactly... that's what i keep saying.
Thus putting the data actually at
/workspaceA/jcr:system would mean that we need to maintain
synchronized copies at /workspaceB/jcr:system,
hi
Assuming we merge SessionInfo and Connection together
for the time being i would like to keep it separated as
from my point of view the result of login to the repository
was something different than operating on the data
contained therein.
furthermore, having slept over the 'Connection'
hi michi
furthermore, having slept over the 'Connection' interface i am not
so confident any more that it's name really fits the purpose
that i was looking for... for me 'Connection' sounds very
vague. i am fine with that for the time being as we are still
very vague and just need something to
hi michi
i am not sure if we can really easily implement things like workspace
management: for example creating a new workspace needs some initial
workspace setup (creating the root node, initial permissions, users) and
i doubt that oak-jcr was the right place to do that.
What about an
hi michi
thanks for commenting. very much appreciated.
I added the removed tests back and marked them as ignored. I think we
should keep them for the time being until we have the same coverage from
another test suite. We can then decide what to do with them.
thanks... that's obviously better
hi all
jukka and myself just were sitting together to define an very
first draft of the oak-api just to have something to start with
and to have a basis for further discussions.
i will commit it as soon as i run the build without error.
it will consist of an initial Service that provides
-
401 - 500 of 509 matches
Mail list logo
