Incompatible Changes to XML-RPC in Trunk

[Catalin Hritcu]

One more change I made now:
- Reversed the order the pages are considered in the page history

Catalin

On 8/18/07, Asiri Rathnayake <asiri.rathnayake at gmail.com> wrote:
> Hi All,
>
> I did a quick and dirty fix to XEclipse to accommodate empty space names.
> Now, all references to space names are diverted to space keys. Later we'll
> refractor the code to remove space name related stuff forever, but for the
> time being this fix will do. I have tested XEclipse with current trunk and
> the current public release and it works with both of them. Anyway, I'll ask
> tharindu to test it further.
>
> Vincent, what else need to be done to make a release of XEclipse ?
>
> Last but not least, sorry about filling your mail boxes.. :)
>
> - Asiri
>
>
> On 8/18/07, Asiri Rathnayake <asiri.rathnayake at gmail.com> wrote:
> > Hi Vincent,
> >
> >
> > On 8/18/07, Vincent Massol < vincent at massol.net> wrote:
> > >
> > >
> > >
> > >
> > > On Aug 17, 2007, at 10:21 PM, Asiri Rathnayake wrote:
> > >
> > > Hi Catalin,
> > >
> > >
> > > On 8/18/07, Catalin Hritcu <catalin.hritcu at gmail.com> 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.
> > >
> > >
> > >
> > > I haven't closely followed but Catalin is your man when it comes to the
> XMLRPC interface :)
> > >
> > >
> > > The only thing I'd like is that XEclipse works ASAP with both XWiki 1.1
> and trunk so that I can release it (btw I'm on holiday now for 1 week but
> I'll try to find some time to the XEClipse release).
> >
> >
> > Ok then, I'll try not to go to server and do something from the client
> side. I'm a bit stuck with some assignments right now, I'll try to put
> something up by today or tomorrow.
> >
> > Thanks.
> >
> > - Asiri
> >
> >
> >
> > >
> > >
> > >
> > > Thanks!
> > > -Vincent
> > >
> > >
> > >
> > >
> > >
> > > > Catalin
> > > >
> > > > On 8/17/07, Asiri Rathnayake <asiri.rathnayake at gmail.com> wrote:
> > > > > Hi Catalin,
> > > > >
> > > > >
> > > > > On 8/17/07, Catalin Hritcu < catalin.hritcu at gmail.com> wrote:
> > > > > > Hi Asiri,
> > > > > >
> > > > > > On 8/17/07, Asiri Rathnayake <asiri.rathnayake at gmail.com> wrote:
> > > > > > > Hi Catalin and all,
> > > > > > >
> > > > > > > On 8/17/07, Catalin Hritcu < catalin.hritcu at gmail.com> 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 < asiri.rathnayake at gmail.com>
> 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 < catalin.hritcu at 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
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>