On 8/18/07, Asiri Rathnayake <asiri.rathnayake@gmail.com> wrote:

Hi Vincent,

On 8/18/07, Vincent Massol < vincent@massol.net> wrote:

On Aug 17, 2007, at 10:21 PM, Asiri Rathnayake wrote:

Hi Catalin,

On 8/18/07, Catalin Hritcu <catalin.hritcu@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@gmail.com> wrote:
> Hi Catalin,
>
>
> On 8/17/07, Catalin Hritcu < catalin.hritcu@gmail.com> wrote:
> > Hi Asiri,
> >
> > On 8/17/07, Asiri Rathnayake <asiri.rathnayake@gmail.com> wrote:
> > > Hi Catalin and all,
> > >
> > > On 8/17/07, Catalin Hritcu < catalin.hritcu@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@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@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
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>