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
Not before tomorrow ;)
I'll reply to Craig tonight.
- Sylvain
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
Have you ever looked at the agsXMPP ( http://www.ag-software.de/index.php )
library?
Brad Jones
Absolutely brilliant David!! This is going to fly! -- Brad
Absolutely brilliant David!! This is going to fly! -- Brad
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
"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 :-)
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!
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/
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
> 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
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
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
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
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.
>
> 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
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