Some news, LLUP, Atom and XMPP

4 views
Skip to first unread message

Sylvain Hellegouarch

unread,
Dec 21, 2006, 6:25:40 AM12/21/06
to ll...@googlegroups.com
Hey folks,

Long time no see. Well as some of you know I've been working for the
last few months on a couple of projects that I felt would be a key to my
next step towards a LLUP implementation.

I've been mainly working a Python implementation [1] of the Atom
Publishing Protocol, trying to make it as flexible as possible in
regards to:

* which storage type it could support
* which media resources it could handle

APP will certainly grow as an important piece within the web and the way
information will be carried in the coming few years. I felt it was
important to provide an implementation as early as possible. Besides it
is a fun project.

This project is now stable enough so that I can move to the next step
which is an XMPP implementation and more particularly of the PubSub [2]
specification and finally Atom-over-XMPP.

Once we have all those pieces we will have a solid infrastructure to
actually work on to build the missing pieces to implement a LLUP service.

In fact little will be left to be done by then since the PubSub
specification covers so much of what LLUP offers.

Within the next three weeks I shall have some working code which I can
demonstrate to you folks.

Until then Merry Xmas and Happy New Year :)
- Sylvain

[1] http://trac.defuze.org/wiki/amplee
[2] http://www.xmpp.org/extensions/xep-0060.html

M. David Peterson

unread,
Dec 21, 2006, 6:34:34 AM12/21/06
to ll...@googlegroups.com
Very nice, Sylvain!

NOTE: While I am already keenly aware of Sylvain's work in this area (we have been working quite closely on several projects), such that the rest of you can gain an understanding of what we have cooking, the nuXleus project is nearing a stage of prime-time readiness, which among LOTS and LOTS of other fun stuff, includes Amplee, which is Sylvain's mentioned APP project.  In fact, as soon as one of the rPath folks comes online this morning and reads my note on IRC, hopefully we can get to the bottom of why the compressed images are being sent as with a text/plain mime-type, and therefore are producing CRC errors when you attempt to unpack them.  Once that is fixed, I will be releasing the now application complete version of nuXleus (though there are still some extensions to the applications that need to be finished off.)

Will make an announcement to this list when the above mentioned problem is fixed.

M. David Peterson

unread,
Dec 21, 2006, 6:35:40 AM12/21/06
to ll...@googlegroups.com
Please append "and he of mine" to "While I am already keenly aware of Sylvain's work in this area" to read,

"While I am already keenly aware of Sylvain's work in this area, and he of mine..."




--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354

Craig Overend

unread,
Dec 21, 2006, 11:07:46 AM12/21/06
to ll...@googlegroups.com
Hi all,

Long time lurker, short time developer here. I'm slowly learning Python and hope to use Kamaelia and Amplee now that it's been added for some personal projects I'm currently researching. I'm looking forward to seeing what comes out of LLUP though. While I don't completely grok LLUP as yet, my conscious tells me its going in a good direction and so I've been keeping an eye out for progress.

Sylvain, on the XMPP front I have a question with regard to whether you'll be writing the XMPP implementation from scratch or using the work in Twisted or even elsewhere? Also, will it use Kamaelia Axon? Just curious if XMPP will be coming to Kamaelia too for me to play with. :)

In a related area; SENA or Scalable Event Notification Architecture[1] internet draft by Benjamin Carlyle came across my path and I thought I'd share here. PubSub done in a RESTful manner makes a lot of sense to me. Reading about Waka[3] has me hoping there may be moves in this direction in the next proposed revision of HTTP[4], but for now I'm interested in learning XMPP.

BTW, thanks for pointing me to nuXleus project M. David! Looks very interesting for areas involving identity security.

Happy programming and Merry Xmas.

Craig.


[1] http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt
[2] http://soundadvice.id.au/blog/
[3] http://gbiv.com/protocols/waka/
[4] http://mail-archives.apache.org/mod_mbox/labs-labs/200611.mbox/%3C4DE0CA70-A508-49E...@gbiv.com%3E

M. David Peterson

unread,
Dec 21, 2006, 11:40:59 AM12/21/06
to ll...@googlegroups.com
Hey Craig,

Thanks for this!  Am looking through the links, and will respond back to this thread as soon as I have a chance.

NOTE: If not mistaken, Sylvain is on his way back home to France for the holiday and won't be back online until Sunday or Monday -- Just wanted to be sure you were aware that he may not respond until that time.

Sylvain Hellegouarch

unread,
Dec 21, 2006, 12:41:56 PM12/21/06
to ll...@googlegroups.com

> NOTE: If not mistaken, Sylvain is on his way back home to France for the
> holiday and won't be back online until Sunday or Monday -- Just wanted
> to be
> sure you were aware that he may not respond until that time.
>

Not before tomorrow ;)
I'll reply to Craig tonight.

- Sylvain

Craig Overend

unread,
Dec 21, 2006, 12:49:05 PM12/21/06
to ll...@googlegroups.com
M.David,

Your welcome and there's no hurry. I'm busily thinking about RESTful web description languages(WDL) at the moment to expose PubSub methods for resources. While it's all hypothetical at the moment, something I'm researching... I'm looking at how to implement versioning - new and depreciation attributes - into a language in order to give it room to evolve(and whether this is a good idea). I hope to get a fixed URI for an API endpoint and a flexible language that can evolve over time. Something forms like without types, simple, discoverable and less brittle than something like WSDL. Practices like Martin Fowler talks about[1]. Eventually I hope to use distributed component servers based on Kamaelia that expose objects and component interfaces as resources that can be subscribed to and/or have operations performed upon. Servers that can talk to one anothers components.
Using something like RFC2774[2] and my agile WDL I hope to expose a RESTful API with either XMPP or SENA methods for specific resources among other Kamaelia component methods that can be performed on a resource. I might be dreaming...but thats the plan as it's currently forming.

Will be busily playing with nuXleus the moment the torrent downloads too. :^)

Craig.

[1] http://channel9.msdn.com/Showpost.aspx?postid=185279
[2] http://www.ietf.org/rfc/rfc2774.txt

Sylvain Hellegouarch

unread,
Dec 21, 2006, 1:41:12 PM12/21/06
to ll...@googlegroups.com

> Long time lurker, short time developer here. I'm slowly learning Python and
> hope to use Kamaelia and Amplee now that it's been added for some personal
> projects I'm currently researching. I'm looking forward to seeing what
> comes
> out of LLUP though. While I don't completely grok LLUP as yet, my conscious
> tells me its going in a good direction and so I've been keeping an eye out
> for progress.

LLUP is fairly close to PubSub in its infrastructure. You have publish
and subscribe services with components in the middle doing the routing
of blip messages.

The main difference is that LLUP adds some specialization to those
services by proposing a way to filter in and out those messages. But if
you get PubSub LLUP is only arms away.

>
> Sylvain, on the XMPP front I have a question with regard to whether you'll
> be writing the XMPP implementation from scratch or using the work in
> Twisted
> or even elsewhere? Also, will it use Kamaelia Axon? Just curious if XMPP
> will be coming to Kamaelia too for me to play with. :)

Well in the "don't reinvent the wheel" spirit I first had a look at the
existing options. Strangely enough the state of XMPP in the Python land
is fairly wobbly if I may say.

You have PyXMPP which is a quite a decent implementation of part of XMPP
but after playing with it I got so frustrated at its (lack) of (good)
documentation and meaningful examples (mind you that reminded me amplee
was far from being perfect in that area). I was spending my time lurking
in its source code which is not a good option to me. Moreover I did not
want to force myself into a specific design. The other XMPP Python
implementations are actually even further away.

Then came idavoll, a Twisted based PubSub service component written by
Ralph Meijer, one of the editor of the XEP 0060. The code is clean and
enjoyable to follow. The big showstopper for me is that it is based on
Twisted which, God forbid, I don't like for many reasons.

1. It's a framework. To me the concept behind a framework is that it
hosts your application. Let me rephrase, your application belongs to the
framework. It's fine but it's a state of mind which locks you in one
given design. This is not my taste. I didn't want either to force
developers using my code to go down that route either.
2. Following a few messages on the Twisted lists, the framework has
become so big that I found that there was long discussions for changing
the slightest thing. There seems to be too much politic going on for my
liking.

Nonetheless I could contact Ralph in a few weeks once my code is viable
in order to test our implementations one against the other.

Regarding Kamaelia, I must admit I am on the tangent on that very point.
K. has a design fairly different from traditional programming (it's not
a negative point here quite the opposite). But K. can be approached as a
framework but this is rather inherent to the approach taken than a goal
per se I think.

Anyway I will try as much as possible to design my library in the same
spirit as amplee. Meaning that it will be independent from any other
toolkits but it will interface itself with them.

For instance because APP relies on a limited interface (GET, POST, PUT,
etc.) it was easy to write interfaces using CherryPy, WSGI or even K.
These interfaces then calling the amplee library.

http://trac.defuze.org/browser/oss/amplee/amplee/handler/store/

Note: The K. interface is still experimental.

- Sylvain

Brad Jones

unread,
Dec 21, 2006, 2:31:37 PM12/21/06
to ll...@googlegroups.com
Sylvain,

Have you ever looked at the agsXMPP ( http://www.ag-software.de/index.php )
library?

Brad Jones

M. David Peterson

unread,
Dec 21, 2006, 2:41:35 PM12/21/06
to ll...@googlegroups.com
Hey Brad,

In fact, I have been working on getting agsXMPP integrated into nuXleus, which would then be available through IronPython (which is now integrated into nuXleus)

Sylvain, lets get in sync on this one, as I agree with Brad -- this is definitely worth taking a look into as a solution.

Brad Jones

unread,
Dec 21, 2006, 3:04:35 PM12/21/06
to ll...@googlegroups.com

Absolutely brilliant David!! This is going to fly! -- Brad

M. David Peterson

unread,
Dec 21, 2006, 3:29:53 PM12/21/06
to ll...@googlegroups.com
On 12/21/06, Brad Jones <pjone...@rogers.com> wrote:

Absolutely brilliant David!! This is going to fly! -- Brad

LLUP or nuXleus? (or both? :D ;))

Michael Sparks

unread,
Dec 21, 2006, 9:36:34 PM12/21/06
to ll...@googlegroups.com
On 12/21/06, Sylvain Hellegouarch <s...@defuze.org> wrote:
..

> Regarding Kamaelia, I must admit I am on the tangent on that very point.
> K. has a design fairly different from traditional programming (it's not
> a negative point here quite the opposite). But K. can be approached as a
> framework but this is rather inherent to the approach taken than a goal
> per se I think.

Incidentally, as well as Kamaelia having some explicit design goals, it's
probably worth me mentioning that it does come out from a research dept,
and as a result experimentation with different kinds of API, and interface
are very much considered a good thing. (Certain core principles need to
stay in place, but that can often be a detail)

Whether or not I agree with an API being the right approach, something
Ward Cunningham said in an interview on artima.com resonates with
me as the right approach to deciding these things:

"I think the best way to do it is A." And they'd say, "I think
the best way to do it is B. I'd say, "Well no, it's really A." And
they'd say, "Well, we want to do B." It was a turning point for
me when I could say, "Fine. Do B. It's not going to hurt us that
much if I'm wrong. It's not going to hurt us that much if I'm right
and you do B, because, we can correct mistakes. So lets find
out if it's a mistake."
....
Usually it turns out to be C. It's a learning experience for both of
us. If we decide without the experience, neither of us really learns.
Ward won, and somebody else didn't. Or vice versa. It's too much
of a battle. Why not say, "Well, let's just code it up and see what
happens. If it doesn't work, we'll change it."
- http://www.artima.com/intv/ownership3.html

As a result, the general "politics" of whether aspects of Kamaelia/Axon can
be extended will generally work on the principle of "give it a go and see if
its useful" and our MiniAxon tutorial is really partly aimed around encouraging
experimentation in that area :-)

> Anyway I will try as much as possible to design my library in the same
> spirit as amplee. Meaning that it will be independent from any other
> toolkits but it will interface itself with them.
>
> For instance because APP relies on a limited interface (GET, POST, PUT,
> etc.) it was easy to write interfaces using CherryPy, WSGI or even K.
> These interfaces then calling the amplee library.
>
> http://trac.defuze.org/browser/oss/amplee/amplee/handler/store/
>
> Note: The K. interface is still experimental.

Regarding the Kamaelia backend, the web serving code is also
at the "the API is not yet fixed in stone" stage, and the following might
be a useful guide:
* http://kamaelia.sourceforge.net/Cookbook/HTTPServer

BTW, given there seems to be a few people on this list interested in getting
to grips with Kamaelia at the moment, it's probably worth me mentioning
the following few URLs:

Developer Console:
http://kamaelia.sourceforge.net/Developers/

Open/Recent Project Tasks (and links to project task pages)
http://kamaelia.sourceforge.net/Developers/Projects

A document about a visual notation for Axon (Kamaelia's core). This
also can serve as a relatively nice overview of certain aspects of
Kamaelia:
http://kamaelia.sourceforge.net/Docs/NotationForVisualisingAxon

I also recently hacked up an MVC example using wxPython which
can be seen here:

http://svn.sourceforge.net/viewvc/kamaelia/trunk/Sketches/MPS/MVC/wxMVC-kamaelia.py?view=markup

I'm not particularly happy with it because it turns out that wxPython
has certain limitations which that example hits (wxPython doesn't
like you putting its MainLoop in a thread like that iit seems causing
issues with widget updates/refresh). It should however show some
interesting principles. (I'll probably change the example to use a web
UI now I think because of this!)

Merry Christmas!


Michael.
--
Michael Sparks, Kamaelia Dust Puppy
http://kamaelia.sourceforge.net/Home
http://yeoldeclue.com/blog

M. David Peterson

unread,
Dec 22, 2006, 2:32:07 AM12/22/06
to ll...@googlegroups.com
Hey Micheal, :)

On 12/21/06, Michael Sparks <spar...@gmail.com> wrote:

    "I think the best way to do it is A." And they'd say, "I think
    the best way to do it is B. I'd say, "Well no, it's really A." And
    they'd say, "Well, we want to do B." It was a turning point for
    me when I could say, "Fine. Do B. It's not going to hurt us that
    much if I'm wrong. It's not going to hurt us that much if I'm right
    and you do B, because, we can correct mistakes. So lets find
    out if it's a mistake."
....
    Usually it turns out to be C. It's a learning experience for both of
    us. If we decide without the experience, neither of us really learns.
    Ward won, and somebody else didn't. Or vice versa. It's too much
    of a battle. Why not say, "Well, let's just code it up and see what
    happens. If it doesn't work, we'll change it."
      - http://www.artima.com/intv/ownership3.html

I *REALLY like that quote!  Very well stated!

As a result, the general "politics" of whether aspects of Kamaelia/Axon can
be extended will generally work on the principle of "give it a go and see if
its useful" and our MiniAxon tutorial is really partly aimed around encouraging
experimentation in that area :-)

Agreed.  I believe that is definitely the right approach.

Regarding the Kamaelia backend, the web serving code is also
at the "the API is not yet fixed in stone" stage, and the following might
be a useful guide:
   * http://kamaelia.sourceforge.net/Cookbook/HTTPServer

Oh, nice!

BTW, given there seems to be a few people on this list interested in getting
to grips with Kamaelia at the moment, it's probably worth me mentioning
the following few URLs:

Developer Console:
    http://kamaelia.sourceforge.net/Developers/

Open/Recent Project Tasks (and links to project task pages)
   http://kamaelia.sourceforge.net/Developers/Projects

A document about a visual notation for Axon (Kamaelia's core). This
also can serve as a relatively nice overview of certain aspects of
Kamaelia:
   http://kamaelia.sourceforge.net/Docs/NotationForVisualisingAxon

Again... Nice!  This is *VERY* helpful!

I also recently hacked up an MVC example using wxPython which
can be seen here:

http://svn.sourceforge.net/viewvc/kamaelia/trunk/Sketches/MPS/MVC/wxMVC-kamaelia.py?view=markup

I'm not particularly happy with it because it turns out that wxPython
has certain limitations which that example hits (wxPython doesn't
like you putting its MainLoop in a thread like that iit seems causing
issues with widget updates/refresh). It should however show some
interesting principles. (I'll probably change the example to use a web
UI now I think because of this!)

Oh, I dig that idea!  Especially from the standpoint of nuXleus, in which the core OS is focused upon a localized web server as it's UI.  've purposely excluded any and all X.org++ packages as I don't want to encourage people to use this as their core host OS.  If people want to add X+DesktopGUI of their choice, there certainly isn't anything stopping them, but for the majority of the people on this planet, if it doesn't come pre-installed, or if it's not immediately obvious how to install it, they won't bother, which in this particular case I see as a good thing.

So again, the WebUI sample would ROCK!!! :D

Merry Christmas!

You too, Michael!

Uche Ogbuji

unread,
Dec 22, 2006, 11:40:37 AM12/22/06
to ll...@googlegroups.com
Craig Overend wrote:
> M.David,
>
> Your welcome and there's no hurry. I'm busily thinking about RESTful web
> description languages(WDL) at the moment to expose PubSub methods for
> resources. While it's all hypothetical at the moment, something I'm
> researching... I'm looking at how to implement versioning - new and
> depreciation attributes - into a language in order to give it room to
> evolve(and whether this is a good idea). I hope to get a fixed URI for
> an API endpoint and a flexible language that can evolve over time.
> Something forms like without types, simple, discoverable and less
> brittle than something like WSDL.

Suggestion: read this thread in its entirety:

http://www.adambosworth.net/archives/000016.html

Among other good wisdom, and occasional WTF moment you'll find

* A link to Prescod's WRDL, which I think kinda proves the next bit

* Roy Fielding himself saying "Why is there no WSDL for REST? Because
HTML is the WSDL for REST, often supplemented by less understandable
choreography mechanisms (e.g., javascript)."

Nothing definitive by any means, but plenty of important food for
thought on the journey you're considering.

G'luck.


--
Uche Ogbuji Work: The Kadomo Group, Inc.
http://uche.ogbuji.net http://kadomo.com
http://copia.ogbuji.net Lead dev at http://4Suite.org
Articles: http://uche.ogbuji.net/tech/publications/

Peter Saint-Andre

unread,
Dec 22, 2006, 12:06:03 PM12/22/06
to ll...@googlegroups.com
Uche Ogbuji wrote:
>
> Craig Overend wrote:
>> M.David,
>>
>> Your welcome and there's no hurry. I'm busily thinking about RESTful web
>> description languages(WDL) at the moment to expose PubSub methods for
>> resources. While it's all hypothetical at the moment, something I'm
>> researching... I'm looking at how to implement versioning - new and
>> depreciation attributes - into a language in order to give it room to
>> evolve(and whether this is a good idea). I hope to get a fixed URI for
>> an API endpoint and a flexible language that can evolve over time.
>> Something forms like without types, simple, discoverable and less
>> brittle than something like WSDL.
>
> Suggestion: read this thread in its entirety:
>
> http://www.adambosworth.net/archives/000016.html

Thanks for that link. I've been trying to grok REST of late and to my
mind the concept is vague. Or, at least, I don't see how it applies to
my world (Jabber/XMPP). For instance, in that thread Mark Baker saith:

***

Re protocol independence, REST says a few things, but one of them is
*not* that HTTP is the only protocol to use. What it does say is that
the use of other protocols is limited to HTTP-like semantics. What that
means, roughly, is that you have to, in effect or in actuality, use an
HTTP proxy in front of all other services. For example, this is how
browsers use FTP.

***

We have some HTTP-like semantics (i.e., request-response semantics) in
XMPP, but they don't happen through an HTTP proxy, instead they happen
natively in our protocol (via the <iq/> stanza).

Similarly for things like availability of services at URIs (we have an
XMPP URI scheme but don't typically use it to express availability of
all resources -- though we could).

So I don't know that Jabberites will ever be good RESTafarians. But I
also don't know that it really matters all that much. :-)

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

Sylvain Hellegouarch

unread,
Dec 22, 2006, 3:57:45 PM12/22/06
to ll...@googlegroups.com
Brad,

> Have you ever looked at the agsXMPP ( http://www.ag-software.de/index.php
> )
> library?

M. David told me about it but I have not yet looked thoroughly at it.
After a quick glance it seemed to be fairly comprehensive :)

It could be interesting to check test my implementations.

- Sylvain

Sylvain Hellegouarch

unread,
Dec 22, 2006, 4:41:25 PM12/22/06
to ll...@googlegroups.com

> Incidentally, as well as Kamaelia having some explicit design goals, it's
> probably worth me mentioning that it does come out from a research dept,
> and as a result experimentation with different kinds of API, and interface
> are very much considered a good thing. (Certain core principles need to
> stay in place, but that can often be a detail)
>
> Whether or not I agree with an API being the right approach, something
> Ward Cunningham said in an interview on artima.com resonates with
> me as the right approach to deciding these things:
>
> "I think the best way to do it is A." And they'd say, "I think
> the best way to do it is B. I'd say, "Well no, it's really A." And
> they'd say, "Well, we want to do B." It was a turning point for
> me when I could say, "Fine. Do B. It's not going to hurt us that
> much if I'm wrong. It's not going to hurt us that much if I'm right
> and you do B, because, we can correct mistakes. So lets find
> out if it's a mistake."
> ....
> Usually it turns out to be C. It's a learning experience for both of
> us. If we decide without the experience, neither of us really learns.
> Ward won, and somebody else didn't. Or vice versa. It's too much
> of a battle. Why not say, "Well, let's just code it up and see what
> happens. If it doesn't work, we'll change it."
> - http://www.artima.com/intv/ownership3.html

Really insightful. Thanks for the link.


>
> As a result, the general "politics" of whether aspects of Kamaelia/Axon
> can
> be extended will generally work on the principle of "give it a go and see
> if
> its useful" and our MiniAxon tutorial is really partly aimed around
> encouraging
> experimentation in that area :-)

I can confirm. The interesting thing with K. is that it challenges the way
you design software and in fact the way you think about software. However
there is a reason why I don't build my libraries as if they were K.
extensions, I want to allow to make it available to the most. Anyway as I
was saying my lib will interface with K. and I already have my idea on how
it will go. This means that plugging an XMPP service into K. should be a
transparent step for K. lovers :)


> Regarding the Kamaelia backend, the web serving code is also
> at the "the API is not yet fixed in stone" stage, and the following might
> be a useful guide:
> * http://kamaelia.sourceforge.net/Cookbook/HTTPServer
>
> BTW, given there seems to be a few people on this list interested in
> getting
> to grips with Kamaelia at the moment, it's probably worth me mentioning
> the following few URLs:
>
> Developer Console:
> http://kamaelia.sourceforge.net/Developers/
>
> Open/Recent Project Tasks (and links to project task pages)
> http://kamaelia.sourceforge.net/Developers/Projects
>
> A document about a visual notation for Axon (Kamaelia's core). This
> also can serve as a relatively nice overview of certain aspects of
> Kamaelia:
> http://kamaelia.sourceforge.net/Docs/NotationForVisualisingAxon
>

All very good links indeed for K. starters. They were really useful to me
and still are :)

- Sylvain

Sylvain Hellegouarch

unread,
Dec 22, 2006, 5:07:27 PM12/22/06
to llup

> In a related area; SENA or Scalable Event Notification Architecture[1]
> internet draft by Benjamin Carlyle came across my path and I thought I'd
> share here.

Good share. The principles declined in his draft are of course quite
common to what PubSub or LLUP (at its base) proposes already but basing
it on HTTP make it deeply relevant today. However I feel his proposal
would make a much stronger impact if it was written as an extension to
the Atom Pub. Protocol. Indeed there had been lots of discussion on the
APP list regarding ways to extend the base protocol itself and
Carlyle's draft would make much sense I think.

- Sylvain

Craig Overend

unread,
Dec 22, 2006, 6:06:00 PM12/22/06
to ll...@googlegroups.com
Thanks Uche,

That thread has resolved some of my nagging thoughts.

I've found that the web-http-desc archives[1] have been a great help aswell. I plan reading as much of them as I can stand before I jump in. It's an area I'm finding that certainly has plenty of food for thought.

I'm already headed towards an HTML forms based approach, possibly Xforms, will see, I haven't finished reading the spec yet. None of the alternatives I've looked at; WSDL, WRDL, and what seems to be the current flavour WADL, or any others - tickle my fancy. They all seem to be mixing semantics along the way. I'm yet to find a good separation of interface and description with any thus far. Nor one that caters for agile development of the language itself. They all appear to force clients to validate the entire spec and then another without a clear upgrade or depreciation path for resources. Any wonder things break. I don't know how they expect humans let alone machines to cope at the pace change happens these days.

Where Roy talks about the value of the web increasing with the creation of new resources really hit home, I'll have to think hard about that, it's been troubling me for a while now. The opposing thought that comes to mind is the question of when is a resource a waste of a resource. Followed immediately with "when it's not used'". Which reminded me of something Martin or Ian said in the talk I linked to earlier in the thread with regard to tracking interface usage in order to drive it's evolution. A mixture of Human Computing and Machine learning in order to do that keeps coming to mind. Ultimately it comes down to who or 'what' is consuming a resource. And increasingly I see interactions happening through abstracted interface layers. Be it human or machine.

I quite enjoyed this quote from Roy and how it related to my readings[2] in the AI arena:
"Generic messaging systems based on interface generators are designed for building systems wherein the data consists of small-grain control messages, such as event-based object monitoring systems. I have yet to see such an interface generator for large-grain messages, streaming data, or even behavioural changes based on what type of representation is received. That doesn't mean it is impossible to design such an interface definition language."

I'm trying to keep an open mind to all this. :)

Craig.

[1] http://lists.w3.org/Archives/Public/public-web-http-desc/
[2] http://www.srcti.com/mproducts.htm

Sylvain Hellegouarch

unread,
Jan 9, 2007, 5:21:44 AM1/9/07
to ll...@googlegroups.com
Hi everyone,

I have worked on my XMPP implementation for the last couple of weeks but
due to my vacation I didn't go as far as I wanted. Anyway I managed to
realize that while not really complicated the XMPP protocol is quite
big. The core protocol is not but all the extensions can be tedious to
follow so it took a little longer than I expected to actually define the
API I wanted (and this is still not a definite one I have implemented so
far).

Anyhow, I came accross an interesting piece of software today and I
though you guys might be ineterested, it's called Telepathy:

http://telepathy.freedesktop.org/wiki/FrontPage

The current spec is there:
http://telepathy.freedesktop.org/spec.html

I let you go through it as I will. I find the basic idea very intuitive
and powerful. If you know about it let me know :)

- Sylvain

Peter Saint-Andre

unread,
Jan 9, 2007, 11:09:50 AM1/9/07
to ll...@googlegroups.com
Sylvain Hellegouarch wrote:
> Hi everyone,
>
> I have worked on my XMPP implementation for the last couple of weeks but
> due to my vacation I didn't go as far as I wanted. Anyway I managed to
> realize that while not really complicated the XMPP protocol is quite
> big. The core protocol is not but all the extensions can be tedious to
> follow so it took a little longer than I expected to actually define the
> API I wanted (and this is still not a definite one I have implemented so
> far).

Well, the pubsub extension is pretty much the biggest of the lot, so you
didn't start with the easiest feature. :-) Most of the other extensions
are fairly small.

> Anyhow, I came accross an interesting piece of software today and I
> though you guys might be ineterested, it's called Telepathy:
>
> http://telepathy.freedesktop.org/wiki/FrontPage
>
> The current spec is there:
> http://telepathy.freedesktop.org/spec.html
>
> I let you go through it as I will. I find the basic idea very intuitive
> and powerful. If you know about it let me know :)

I know some of the guys who work on that project, let me know if you'd
like me to hook you up.

Sylvain Hellegouarch

unread,
Jan 9, 2007, 2:13:37 PM1/9/07
to ll...@googlegroups.com
Hi Peter,

>
> Well, the pubsub extension is pretty much the biggest of the lot, so you
> didn't start with the easiest feature. :-) Most of the other extensions
> are fairly small.

I realized that yeah. But that's the most interesting from my requirement ;)

> I know some of the guys who work on that project, let me know if you'd
> like me to hook you up.

Well I will first look more thoroughly at the project and how I can use
it then I could definitely need a white card yes :) Thanks.

- Sylvain

Alexander Gnauck

unread,
Jan 12, 2007, 5:53:13 AM1/12/07
to llup
Hello,

we just released the latest version og asgXMPP. One of the major
changes was a licence change. You are able to use it under GPL now.
Contact me for help regarding agsXMPP

Alex

M. David Peterson

unread,
Jan 12, 2007, 6:00:35 AM1/12/07
to ll...@googlegroups.com
Hi Alexandar,

HOLY MOLY!  That ROCKS!!!

Will download the new release and get it integrated into nuXleus right away.  Once I have it integrated, I will ping back this thread such that we can begin to start using this to build and extend from in regards to LLUP-related implementation.

Thanks Alexander!

xmlh...@gmail.com

unread,
Jan 12, 2007, 7:06:15 AM1/12/07
to llup
Reply all
Reply to author
Forward
0 new messages