[Moonbeam-users] Re: moonbeam 0.3.1

[Heiko B. <he...@op...>]

Hi,
it's been quiet a while since we last talked to each other.
Sorry for that, i have been quiet busy working on other projects.

Introduction
------------
Marcel, i put Kris on the list, he joined the moonbeam
development about two weeks ago.

Kris, this is Marcel, he plans to use moonbeam on a flash project.


Updates
-------

I checked in a lot of code today. the current cvs label is "mb-0-40".
moonbeam 0.40 brings some interesting features, that are mostly targeted
to the limitations of the message format regarding extensibility.
(see the attached discussion between marcel and me)

One of the major problems we saw, was the fact that besides the
core elements (message,presence,iq) we needed a way to handle further
elements that are bound to specific engine implementations.=20
(espacially in an 'iq' element).

For example:
What happens if you want to send a list of members in your current
group? the prior implementation used string represenations like
"[default,red,green]", but it would be much better to send it xml
formated, like :

<iq type=3D"result">
	<group>default</group>
	<group>red</group>
	<group>green</group>
</iq>

(thanks for the input marcel)

I moved the java/xml binding to the latest jaxb=20
(http://java.sun.com/xml/jaxb/) version which is xml schema
based and much easier to work with.

as a result, all binding classes=20
are now split into the core elements (message,presence,iq),
which reside under openj.moonbeam.binding.*
and custom extensions, under openj.moonbeam.binding.custom.*.

the bindings can be specified in the schema files src/dtd/common.xsd
and src/dtd/custom.xsd.=20

the build file is extended by a target called "create-binding",
which will generate all java code necessary for moonbeam to be able
to handle custom extensions.

if you want to extend the core element contents,
you simply need to add your element description to the
src/dtd/custom.xsd file and run the "create-binding" and "compile"
target afterwards.

from that point on, you can send messages containing your custom
elements, and moonbeam will be able to parse and deliver these messages.
for now, the extension only works for 'iq' elements, it is open for
discussion if we need more flexibility in 'message' and 'presence' as
well.


NOTE:
due to the heavy changes, moonbeam 0.3 will not be compatible with=20
moonbeam 0.4. therefore i had to remove the sample engine from
src/java/app, because they are not going to work anymore.

Getting the source
------------------

for now, you can get the sources straight from cvs,
using the 'mb-0-40' label. i will release the files=20
at the weekend.

let me know if you have any questions.

Mailing list
------------
we should move further discussions to the mailing lists
in order to make the result available to the rest of the world.


rock on fellows,
heiko

Attched: Message Format Discussion
----------------------------------

On Fri, 2003-03-21 at 09:27, Lelkes Marcell wrote:
> >
> > i thought about that as well.
> > it is a problem with datatype conversion in general.
> > you can break it down into simple and comlex datatypes
> > for get/set iq's:
> >
> > a simple type example
> >
> > <attribute name=3D"myAtt" value=3D"myValue"/>
> >
> > a complex type:
> >
> > <user id=3D"12342">
> >         <name=3D"peter"/>
> >         <email=3D"pe...@mo...">
> > </user>
> >
> > both types can be used as return values,
> > eiter as a single value or as an array of values.
> >
> > i think we should support the complex types.
> > but this means that moonbeam needs to know a lot
> > more elements, or on the other hand, be able to process
> > unkown elments:
> >
> > <iq type=3D"result">
> >
> >         // put any element here
> >
> > </iq>
> >
> > i guess, supporting unknown elements would be the
> > best solution, since everything else means additional
> > binding classes for every element.
> >
>=20
> Then, what format should be chosen to report the
> group members list / group list as an iq result?
> E.g.:
> <iq type=3D"result">
> <groupmember>peter</groupmember>
> <groupmember>charly</groupmember>
> <groupmember>karl</groupmember>
> </iq>
>=20
> <iq type=3D"result">
> <group>default</group>
> <group>red</group>
> <group>green</group>
> </iq>
>=20
>=20
> >
> > > 2. How does the server respond when two different clients
> > > want to set the same client name? Is it possible to have different
> > > clients/groups with the same name?
> >
> > no, a client name has to be distinct throughout groups.
> > otherwise we run into trouble when the same names occur
> > in the same group and you try to send to this name.
> >
> > moonbeam should tell you that the name is already taken.
> >
>=20
> Do you already know the return message format?
>=20
> >
> > > 3. "A client is always in a group and in one group only."
> > > But one user may run multiple clients from the same
> > > machine, right? Will this user be able to use the same
> > > client name in every client? (See previous question.)
> >
> > yup, multiple client from the same host/machine,
> > but different names.
> >
> > the names act as aliases only. for every name the server
> > keeps a distinct client id.
> >
>=20
> In future versions, I think it would be useful to let a
> user join different groups with the same client name.
> (For now, I don't think it's vital, but this should be considered
> when you make decisions about the server structure.)
>=20
> >
> >
> > ;)
> >
> > lovely!
> >
> > i am developing, working and living on debian.
> >
>=20
> Great. I love debian, though I also have to use MS
> systems. Which java package(s) do you recommend
> for using moonbeam? Blackdown?
>=20
> Bye,
> Marcell