Re: open issues

[Kurt Ward <ku...@yahoo.com>]

> > OK guys; sorry for having not responded earlier... I've been kind of
busy
> > (at the OpenCMS conference in Zürich; Xindice was mentioned 3 times!
> > Yippie...) and will be busy for a few more days on some non-Xindice
stuff.
> > .. However after that, I fully intend once again to participate actively
> > in the project.
> >
> > Some points I'd like to mention:
> >
> > - about the internal RPC API:
> > ====================
> > Kimbro you proposed a solution passing big hashtables back and forth
> > accross the RPC tool. I'm sorry, but I don't see the point? At the
> > bear-bones level, you'll always need server code that implements the
> > various methods/functions/operations/whatever-you-call-them with the
> > appropriate arguments that you need. If you want to add a new
> > method/function/whatever, you'll still have to add server code...
>
> Ahh, OK. Let me explain further, there is a point and I still believe it's
> a worthy one. I was hoping the experimental implementation would be enough
> to make it clear where the potential lies. This is one of those times I
> wish we could just get together in front of a whiteboard and hash it out.
>
> The problem is simply that adding parameters to existing method calls
> changes the signature of those method calls. This automatically breaks all
> existing clients even in cases where those clients may not need to have
> been broken. Basically my goal is for the API to be easy to change. We
> need this because there is so much about what we're doing that is still
> really fuzzy.
>
> Let's take an example of transactions. The current API as designed does
> not support transactions. So how do we add transaction support? Well for
> one thing we're probably going to have to pass around a transaction ID of
> some type and this ID will need to be passed to any method that operates
> within the context of that transaction. This change to the existing API
> will break all current clients because the method signatures will have to
> change. This is unnecessary breakage though, as those clients could have
> continued to work with an implicit transaction model. The transaction ID
> is a completely optional parameter, but the traditional RPC model forces
> you to deal with it even if you don't want to.
>
> Another example is a method to configure some object, let's say indexes.
> What happens when we add a new index type like full text indexing that may
> require different parameters to configure it? In a standard RPC API you
> break all clients that call that method and force them to deal with the
> fact that you added those parameters. When in reality, they could have
> continued to work in blissful contentment, ignorant of the fact that full
> text even existed in the server.
>
> Really this is a problem because we're using Java and the XML-RPC
> implementation uses both the method name and its signature to find the
> method to call. XML-RPC was originally designed to be used with scripting
> languages and it usually only uses the method name to locate the code to
> call. This allows the parameter list to be fuzzy. In the Apache XML-RPC
> impl you can achieve this by implementing XmlRpcHandler, however you're
> still relying on parameter order to resolve things.
>
> You of course have to add server code to add new functionality, however if
> you look at the implementation what you're adding is a class not a method
> to a class.  You can add classes at any time very easily. Also to add a
> parameter to a message you simply change the internals of the class not
> the public signature.  This makes the API much more malleable without
> automatically breaking clients.
>
> Yes there will be cases where you want to add a parameter and make it
> required, but that is a simple check that should generate an informative
> error message from the class.

Thanks for the explanation on this.  I now see what you are trying to
achieve
and it does make a lot of sense.

> Also I really want to replace XMLObjects with user definable API messages.
>   It's a massively simpler model then the heavy introspection based model
> of XMLObjects and will be much easier to call over the wire.

I like the idea of replacing XMLObjects with something a little easier to
use as long
as the replacement provides the same flexibility.  I've started using them
(XMLObjects)
more and have really grown to like them.  What do you have in mind?

Kurt



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com