New subject: Incompatible Changes to XML-RPC in Trunk

17 Aug 2007

Hi Catalin,

On 8/18/07, Catalin Hritcu &lt;catalin.hritcu(a)gmail.com&gt; wrote:
...

 Asiri,

 I would go with 1, or 3 but done on the client instead of wasting time
 writing emails. The xml-rpc interface is not only for XEclipse to use
 and it will stay as general and clear as possible. 

Hmmmm... That sounds like a good idea.

I think we could go with the third option but still on the client side.  And
the amount of work to be done would be really less. I didn't think about
this before, thanks.... (still, i need to check what needs to be changed).

But anyway, I'm waiting for Vincent's confirmation.

Regards,

- Asiri

Catalin
...

 On 8/17/07, Asiri Rathnayake &lt;asiri.rathnayake(a)gmail.com&gt; wrote:
  Hi Catalin,

 On 8/17/07, Catalin Hritcu &lt;catalin.hritcu(a)gmail.com&gt; wrote:
 > Hi Asiri,
 >
 > On 8/17/07, Asiri Rathnayake &lt;asiri.rathnayake(a)gmail.com&gt; wrote:
 > > Hi Catalin and all,
 > >
 > > On 8/17/07, Catalin Hritcu < catalin.hritcu(a)gmail.com&gt; wrote:
 > > > Hi Asiri,
 > > >
 > > > Why don't you use the space key? It used to be that the title was
 > > > always set to this key. If you were setting a title different then 
the
  > > > key then this title was just
discarded and the key was returned.  That
  > > > was not normal.
 > > >
 > > > Now about space titles being empty, this is a possible situation 
in
  > > > XWiki (document titles can also be
empty). If you want to treat  this
  > > > situation differently why not do
it on the client side ? And if  you
  > > > need to use the space key, then
just use the space key and forget
 > > > about the title.
 > >
 > > This is the issue, at the  beginning of XEclipse, we thought a key  was
  > > something that should be used to refer
to documents within programs  (not
   >
displayed to users) - This is the purpose of a key (a unique  identifier). I
  > think it is necessary we keep this
terminology since otherwise we'll  violate
 > > the whole purpose of a key (please someone correct me if this is not 
the
    purpose of a key).
  Yes, a key does identify a space, but it is not cryptic like the IDs
 used in the API (the IDs are numbers in confluence, and opaque strings
 in XWiki). You can display a key to an user without problems. So yes,
 keys are identifiers, and no keys are not supposed to be hidden from
 the user like the PageID, CommentID etc. 
 Isn't the whole point of having a space name / title is to display it
 whenever possible ? I mean, if we use space keys in XEclipse, that means
 we're not being user friendly - assuming titles are more expressive than
 keys.

 > > Now titles on the other hand are what users understand
 > > (what we should display to them) and I think we should not allow  them
to
  be
  > empty - but in case if a title is not
available, we can use the key  (since
   there is
no other option).
  Yes, titles (or space names) can be more expressive. In particular
 they can contain spaces, be longer etc. In XWiki they are displayed in
 a special field on top of the edit box (which btw is empty by
 default).

 Most important these two properties of a space can be changed
 independently, and the value of one should not influence the value of
 the other. This is what the current implementation does. 
 Agreed.

 > > So in summary, XEclipse was developed with the assumptions,
 > >
 > > 1. Keys should be used whenever we refer to documents within  programs
  (like
  > when invoking XMLRPCs).
 >
 > 2. Keys should be mapped into titles (or names) when a document is  presented
   to a
user.
  I think you make a major confusion between space keys and IDs. They
 are not the same, see above. Your statements here are true only for
 IDs not for space keys. 
 Ok, didn't know about this. The word "key" always brings a cryptic
 identifier to my mind....

  > We can change XEclipse to use keys only and
forget about titles, but  that
  > will take some more time. And most
importantly, this might affect  XEclipse
   on XWiki
1.1.
  Not true. On XWiki 1.1 the title/name was always equal to the key, so
 whenever you thought you were using the title/name you were actually
 using the key. Now you would use the key explicitly.
  Anyway, in my personal opinion, i think it's
necessary we keep the
 distinction between keys and titles intact.
  This is exactly what i did. They used to be the same, now there is a
 clear distinction between the two. 
 I too thought of them separately and expected them to be different.  Anyway,
  with the current scheme, we cannot use space
names / titles alone on
 XEclipse since some names can be empty (as you said). So now there are  three
  possibilities,

 1.  Use space keys only in client (for everything) - Then what  is the  use
  of space names / titles ? <-- have to answer
if we are to go with this
 option. And this requires XEclipse to be changed.

 2. Enforce spaces to have a title ( a.k.a not ""). <-- Ideal scenario.

 3. Use titles / names whenever they are available and switch to space  keys
  otherwise - this should be done on server (see my
patch). <-- This is
 possible since space keys and titles / names can be changed  independently.
  The only disadvantage of this scheme is that
sometimes users get to see  a
  title / name of a space which is not the actual
title (when actual title  is
  "").

 I would go with the third option.

 What would you think ?

 Regards,

 - Asiri

 > Regards,
 > Catalin
 >
 > > > On 8/17/07, Asiri Rathnayake &lt;asiri.rathnayake(a)gmail.com&gt; wrote:
 > > > > Hi All,
 > > > >
 > > > > Sorry about the late response. Busy with academic work :(
 > > > >
 > > > > The patch attached will fix the XMLRPC issue related to 
XEclipse.
  Please
  > > > verify it and let me know what you
think.
 > > > I tested XEclipse with this patch and everything is normal now.
 > > >
 > > > Regards,
 > > >
 > > > - Asiri
 > > >
 > > >
 > > > On 8/16/07, Catalin Hritcu &lt;catalin.hritcu(a)gmail.com > wrote:
 > > > > Hi,
 > > > >
 > > > > I updated the xml-rpc implementation on trunk. There are big 
changes
  > > > > so be careful when updating
since some of the changes are
 > > > > incompatible.
 > > > > - all non-string primitive types (like date and int) are now 
encoded
 > > to
 > > > > strings
 > > > > > the easiest to adapt to this is to start using swizzle which
 makes
  the
 > > > > > translation automatic
 > > > > > - the way all identifiers are built has changed
 > > > > > anyway, ids should be treated as opaque handlers, so if you
 ever
  find
  > > > > yourself parsing them then
you are doing something wrong.
 > > > > - the way the page history is different now
 > > > > only old versions of the page are considered, and they can be 
accessed
 > > > > > like regular pages
 > > > > >
 > > > > > There are other smaller fixes, but these are the most 
important
  ones.
   > >
>
 > > > Regards,
 > > > Catalin
 > > >
 > >
 > >
 > >
 >

Re: Incompatible Changes to XML-RPC in Trunk