XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (but not for xwiki-core-1.2-SNAPSHOT)
Hello, Until now I have refrained from making API breaking changes in XML-RPC in order to keep compatibility with XEclipse. However, these changes are necessary and cannot be delayed forever, so after the release of XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need to be moved to swizzle-confluence. I volunteer to make this change happen in the XEclipse trunk once XEclipse 1.0M1 is released. To sum things up: - XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the remaining releases on the 1.1 branch) - XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later WDYT ? Catalin
Hi Catalin, On Aug 27, 2007, at 12:07 PM, Catalin Hritcu wrote:
Hello,
Until now I have refrained from making API breaking changes in XML-RPC in order to keep compatibility with XEclipse. However, these changes are necessary and cannot be delayed forever, so after the release of XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need to be moved to swizzle-confluence. I volunteer to make this change happen in the XEclipse trunk once XEclipse 1.0M1 is released.
To sum things up: - XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the remaining releases on the 1.1 branch) - XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later
WDYT ?
I think it's important that XEclipse 1.0M2 (and thus XEclipse 1.0) also work with XWiki 1.1 since XWiki 1.2 is not going to be released and in use for several months while we're just releasing XWiki 1.1. So I'm +1 to use sizzle but also to keep some "compatibility layer" in XEclipse so that it also works with XWiki 1.1 final. Is that possible? Thanks -Vincent
Hi Vincent, On 8/27/07, Vincent Massol <[email protected]> wrote:
Hi Catalin,
On Aug 27, 2007, at 12:07 PM, Catalin Hritcu wrote:
Hello,
Until now I have refrained from making API breaking changes in XML-RPC in order to keep compatibility with XEclipse. However, these changes are necessary and cannot be delayed forever, so after the release of XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need to be moved to swizzle-confluence. I volunteer to make this change happen in the XEclipse trunk once XEclipse 1.0M1 is released.
To sum things up: - XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the remaining releases on the 1.1 branch) - XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later
WDYT ?
I think it's important that XEclipse 1.0M2 (and thus XEclipse 1.0) also work with XWiki 1.1 since XWiki 1.2 is not going to be released and in use for several months while we're just releasing XWiki 1.1.
Why is not enough for XEclipse 1.0M1 to work with XWiki 1.1? If by the time XEclipse 1.0M2 is released the first milestone for XWiki 1.1 is already available, then I really don't see a problem.
So I'm +1 to use sizzle but also to keep some "compatibility layer" in XEclipse so that it also works with XWiki 1.1 final.
Is that possible?
Maybe it's possible, but it's against the very purpose of this change. The purpose of this change proposal was to simplify the whole thing and remove the duplication (and triplication in many places). A "compatibility layer" would only make things worse here = more complex and error prone. There are already too many layers. I think we should not stifle progress for bug-per-bug, lack-of-feature-per-lack-of-feature backwards compatibility. The most you can get out of the XWiki 1.1 XML-RPC is already exploited in XEclipse 1.0M1, and will definitely(!) not be enough very soon. Change is unavoidable. Regards, Catalin
Just a small bug, On 8/27/07, Catalin Hritcu <[email protected]> wrote:
Hi Vincent,
On 8/27/07, Vincent Massol <[email protected]> wrote:
Hi Catalin,
On Aug 27, 2007, at 12:07 PM, Catalin Hritcu wrote:
Hello,
Until now I have refrained from making API breaking changes in XML-RPC in order to keep compatibility with XEclipse. However, these changes are necessary and cannot be delayed forever, so after the release of XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need to be moved to swizzle-confluence. I volunteer to make this change happen in the XEclipse trunk once XEclipse 1.0M1 is released.
To sum things up: - XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the remaining releases on the 1.1 branch) - XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later
WDYT ?
I think it's important that XEclipse 1.0M2 (and thus XEclipse 1.0) also work with XWiki 1.1 since XWiki 1.2 is not going to be released and in use for several months while we're just releasing XWiki 1.1.
Why is not enough for XEclipse 1.0M1 to work with XWiki 1.1? If by the time XEclipse 1.0M2 is released the first milestone for XWiki 1.1 is
I the first milestone for XWiki 1.2, of course ;)
already available, then I really don't see a problem.
So I'm +1 to use sizzle but also to keep some "compatibility layer" in XEclipse so that it also works with XWiki 1.1 final.
Is that possible?
Maybe it's possible, but it's against the very purpose of this change. The purpose of this change proposal was to simplify the whole thing and remove the duplication (and triplication in many places). A "compatibility layer" would only make things worse here = more complex and error prone. There are already too many layers. I think we should not stifle progress for bug-per-bug, lack-of-feature-per-lack-of-feature backwards compatibility. The most you can get out of the XWiki 1.1 XML-RPC is already exploited in XEclipse 1.0M1, and will definitely(!) not be enough very soon. Change is unavoidable.
Catalin
On Aug 27, 2007, at 2:35 PM, Catalin Hritcu wrote:
Hi Vincent,
On 8/27/07, Vincent Massol <[email protected]> wrote:
Hi Catalin,
On Aug 27, 2007, at 12:07 PM, Catalin Hritcu wrote:
Hello,
Until now I have refrained from making API breaking changes in XML-RPC in order to keep compatibility with XEclipse. However, these changes are necessary and cannot be delayed forever, so after the release of XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need to be moved to swizzle-confluence. I volunteer to make this change happen in the XEclipse trunk once XEclipse 1.0M1 is released.
To sum things up: - XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the remaining releases on the 1.1 branch) - XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later
WDYT ?
I think it's important that XEclipse 1.0M2 (and thus XEclipse 1.0) also work with XWiki 1.1 since XWiki 1.2 is not going to be released and in use for several months while we're just releasing XWiki 1.1.
Why is not enough for XEclipse 1.0M1 to work with XWiki 1.1? If by the time XEclipse 1.0M2 is released the first milestone for XWiki 1.1 is already available, then I really don't see a problem.
What I mean is that XEclipse 1.0M1, 1.0M2 or even XEclipse 1.0 final should work with XWiki 1.1 and not only with XWiki 1.2.
So I'm +1 to use sizzle but also to keep some "compatibility layer" in XEclipse so that it also works with XWiki 1.1 final.
Is that possible?
Maybe it's possible, but it's against the very purpose of this change. The purpose of this change proposal was to simplify the whole thing and remove the duplication (and triplication in many places). A "compatibility layer" would only make things worse here = more complex and error prone. There are already too many layers. I think we should not stifle progress for bug-per-bug, lack-of-feature-per-lack-of-feature backwards compatibility. The most you can get out of the XWiki 1.1 XML-RPC is already exploited in XEclipse 1.0M1, and will definitely(!) not be enough very soon. Change is unavoidable.
It's only a question of how of migration. I really think we want people to use XEclipse with XWiki 1.1 and not have to wait 4 months before being able to try it out... -Vincent
Should have hit reply-to all :) ---------- Forwarded message ---------- From: Catalin Hritcu <[email protected]> Date: Aug 27, 2007 4:08 PM Subject: Re: XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (but not for xwiki-core-1.2-SNAPSHOT) To: Vincent Massol <[email protected]> Hi Vincent, Thought about it a little more. On 8/27/07, Vincent Massol <[email protected]> wrote:
On Aug 27, 2007, at 2:35 PM, Catalin Hritcu wrote:
Hi Vincent,
On 8/27/07, Vincent Massol <[email protected]> wrote:
Hi Catalin,
On Aug 27, 2007, at 12:07 PM, Catalin Hritcu wrote:
Hello,
Until now I have refrained from making API breaking changes in XML-RPC in order to keep compatibility with XEclipse. However, these changes are necessary and cannot be delayed forever, so after the release of XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need to be moved to swizzle-confluence. I volunteer to make this change happen in the XEclipse trunk once XEclipse 1.0M1 is released.
To sum things up: - XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the remaining releases on the 1.1 branch) - XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later
WDYT ?
I think it's important that XEclipse 1.0M2 (and thus XEclipse 1.0) also work with XWiki 1.1 since XWiki 1.2 is not going to be released and in use for several months while we're just releasing XWiki 1.1.
Why is not enough for XEclipse 1.0M1 to work with XWiki 1.1? If by the time XEclipse 1.0M2 is released the first milestone for XWiki 1.1 is already available, then I really don't see a problem.
What I mean is that XEclipse 1.0M1, 1.0M2 or even XEclipse 1.0 final should work with XWiki 1.1 and not only with XWiki 1.2.
So I'm +1 to use sizzle but also to keep some "compatibility layer" in XEclipse so that it also works with XWiki 1.1 final.
Is that possible?
Maybe it's possible, but it's against the very purpose of this change. The purpose of this change proposal was to simplify the whole thing and remove the duplication (and triplication in many places). A "compatibility layer" would only make things worse here = more complex and error prone. There are already too many layers. I think we should not stifle progress for bug-per-bug, lack-of-feature-per-lack-of-feature backwards compatibility. The most you can get out of the XWiki 1.1 XML-RPC is already exploited in XEclipse 1.0M1, and will definitely(!) not be enough very soon. Change is unavoidable.
It's only a question of how of migration. I really think we want people to use XEclipse with XWiki 1.1 and not have to wait 4 months before being able to try it out...
We might be able to do this only with swizzle itself as the "compatibility layer". One of the features I added in my last patch to swizzle allows us to select the way conversion is done for non-string types. This together with a working getServerInfo function (both on trunk and branch) and some code that makes a distinction on the client could give us compatibility with both xwiki 1.1 and 1.2. I'll look more into it, Catalin
Hi All, I'm still about to look into swizzle. What's surprising is that myself and tharindu has implemented a little swizzle proxy ourselves (it seems like that). It's bit disappointing that we have re-invented something already there. Anyway, i'm concerned if we have to change a lot of code in XEclipse to use swizzle (ex. dump our domain model and use swizzle's own) - will get back once i have gone through swizzle code. thanks. - Asiri ps : I agree that it's better to use a standard (swizzle) than creating our own (what we have done). On 8/27/07, Catalin Hritcu <[email protected]> wrote:
Should have hit reply-to all :)
---------- Forwarded message ---------- From: Catalin Hritcu <[email protected]> Date: Aug 27, 2007 4:08 PM Subject: Re: XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (but not for xwiki-core-1.2-SNAPSHOT) To: Vincent Massol <[email protected]>
Hi Vincent,
Thought about it a little more.
On 8/27/07, Vincent Massol <[email protected]> wrote:
On Aug 27, 2007, at 2:35 PM, Catalin Hritcu wrote:
Hi Vincent,
On 8/27/07, Vincent Massol <[email protected]> wrote:
Hi Catalin,
On Aug 27, 2007, at 12:07 PM, Catalin Hritcu wrote:
Hello,
Until now I have refrained from making API breaking changes in XML-RPC in order to keep compatibility with XEclipse. However, these changes are necessary and cannot be delayed forever, so after the release of XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need to be moved to swizzle-confluence. I volunteer to make this change happen in the XEclipse trunk once XEclipse 1.0M1 is released.
To sum things up: - XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the remaining releases on the 1.1 branch) - XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later
WDYT ?
I think it's important that XEclipse 1.0M2 (and thus XEclipse 1.0) also work with XWiki 1.1 since XWiki 1.2 is not going to be released and in use for several months while we're just releasing XWiki 1.1.
Why is not enough for XEclipse 1.0M1 to work with XWiki 1.1? If by the time XEclipse 1.0M2 is released the first milestone for XWiki 1.1 is already available, then I really don't see a problem.
What I mean is that XEclipse 1.0M1, 1.0M2 or even XEclipse 1.0 final should work with XWiki 1.1 and not only with XWiki 1.2.
So I'm +1 to use sizzle but also to keep some "compatibility layer" in XEclipse so that it also works with XWiki 1.1 final.
Is that possible?
Maybe it's possible, but it's against the very purpose of this change. The purpose of this change proposal was to simplify the whole thing and remove the duplication (and triplication in many places). A "compatibility layer" would only make things worse here = more complex and error prone. There are already too many layers. I think we should not stifle progress for bug-per-bug, lack-of-feature-per-lack-of-feature backwards compatibility. The most you can get out of the XWiki 1.1 XML-RPC is already exploited in XEclipse 1.0M1, and will definitely(!) not be enough very soon. Change is unavoidable.
It's only a question of how of migration. I really think we want people to use XEclipse with XWiki 1.1 and not have to wait 4 months before being able to try it out...
We might be able to do this only with swizzle itself as the "compatibility layer". One of the features I added in my last patch to swizzle allows us to select the way conversion is done for non-string types. This together with a working getServerInfo function (both on trunk and branch) and some code that makes a distinction on the client could give us compatibility with both xwiki 1.1 and 1.2.
I'll look more into it, Catalin
Hi All, I did a preliminary analysis about swizzle and the possibility of using it withing xeclipse rather than using raw xmlrpc invocations (this is how we currently communicate with server - raw xmlrpc). As i understood (correct me if i'm wrong) swizzle is a nice wrapper for the raw xmlrpcs and handles a lot of low level information such as object serialization, de-serialization, exception handling and session management. Apart from that, it has it's own domain object model (pages, spaces, attachments and so and so on). I really feel guilty about not looking into swizzle little earlier because currently XEclipse is tightly coupled into our own domain model. In other words, we have implemented our own wrappers for raw xmlrpcs within XEclipse which pretty much resembles swizzle (but not that powerful). In my opinion, changing XEclipse to use swizzle requires a lot of changes into XEclipse code. This is primarily because XEclipse' functionality is tightly bound to the domain model we developed for XEclipse. For an example, in XEclipse we have the hierarchy; Connection -> Space -> Page (A single connection for a session, many spaces under a connection and pages under spaces) A lot of code in XEclipse depends on this model. But such a model is not present in swizzle. I was just having a thought, what's wrong if XEclipse continue to use raw xmlrpcs rather than switching to swizzle ? what sort of problems / disadvantages this would imply ? And Catalin, by "moving to swizzle-confluence" did you mean that we should make XEclipse use swizzle or did you mean that the back-end API would change ? Thanks. - Asiri On 8/27/07, Catalin Hritcu <[email protected]> wrote:
Hello,
Until now I have refrained from making API breaking changes in XML-RPC in order to keep compatibility with XEclipse. However, these changes are necessary and cannot be delayed forever, so after the release of XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need to be moved to swizzle-confluence. I volunteer to make this change happen in the XEclipse trunk once XEclipse 1.0M1 is released.
To sum things up: - XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the remaining releases on the 1.1 branch) - XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later
WDYT ?
Catalin
Hi Asiri/Catalin, On Aug 27, 2007, at 8:36 PM, Asiri Rathnayake wrote:
Hi All,
I did a preliminary analysis about swizzle and the possibility of using it withing xeclipse rather than using raw xmlrpc invocations (this is how we currently communicate with server - raw xmlrpc).
As i understood (correct me if i'm wrong) swizzle is a nice wrapper for the raw xmlrpcs and handles a lot of low level information such as object serialization, de-serialization, exception handling and session management. Apart from that, it has it's own domain object model (pages, spaces, attachments and so and so on).
I really feel guilty about not looking into swizzle little earlier because currently XEclipse is tightly coupled into our own domain model. In other words, we have implemented our own wrappers for raw xmlrpcs within XEclipse which pretty much resembles swizzle (but not that powerful). In my opinion, changing XEclipse to use swizzle requires a lot of changes into XEclipse code. This is primarily because XEclipse' functionality is tightly bound to the domain model we developed for XEclipse.
For an example, in XEclipse we have the hierarchy; Connection -> Space -> Page (A single connection for a session, many spaces under a connection and pages under spaces) A lot of code in XEclipse depends on this model. But such a model is not present in swizzle.
I was just having a thought, what's wrong if XEclipse continue to use raw xmlrpcs rather than switching to swizzle ? what sort of problems / disadvantages this would imply ?
Pros: * A single way for all xwiki clients to connect to XWiki servers * Less maintenance, less documentation, less work in general since someone else is developing swizzle :). This point only is huge. * Possibility to add new actions for XWiki-specific stuff missing in swizzle (I haven't checked but Catalin says it's extensible) Cons: * Need to refactor current XEclipse implementation to use Swizzle. * If swizzle goes away or is abandonned then it'll be bad for xwiki and we'd need to support it/reintegrate it. Actually this is a point that is bothering me Catalin. I think we'd need our own object model and expose that as a component and then provide a default implementation using swizzle behind the hood. Same as what we're doing for everything. This will also make the API seamless WRT extra APIs we have for xwiki (like getting objects, etc). So IMO: * We shouldn't use swizzle directly * We should develop our own client side Java Objects and API *interface* for people interacting with XWiki remotely. - That API should be independent of the protocol used. - A default implementation should be done using swizzle. It'll be mostly empty and only call out swizzle objects/swizzle APIs * XEClipse should be refactored to use this API * This API should be developed using components and using the new org.xwiki namespace. WDYT?
And Catalin, by "moving to swizzle-confluence" did you mean that we should make XEclipse use swizzle or did you mean that the back-end API would change ?
I think he meant "XEclipse uses swizzle". Thanks -Vincent
On 8/27/07, Catalin Hritcu <[email protected]> wrote: Hello,
Until now I have refrained from making API breaking changes in XML-RPC in order to keep compatibility with XEclipse. However, these changes are necessary and cannot be delayed forever, so after the release of XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need to be moved to swizzle-confluence. I volunteer to make this change happen in the XEclipse trunk once XEclipse 1.0M1 is released.
To sum things up: - XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the remaining releases on the 1.1 branch) - XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later
WDYT ?
Catalin
participants (3)
-
Asiri Rathnayake -
Catalin Hritcu -
Vincent Massol