Inline.
"Maniac" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> separation. This is bad (allow me not to descend into an academic-style
> discussion why).
I am with you.
> What I was trying to say is that I'm agains 'Ajax support' only if it
> means what I described above -
Eugene Lazutkin wrote:
Care to share these reasons or provide a link to reasons you support?
Unfortunately all this client-server separation is a marriage of
convenience, which is mostly created by network speed. Trust me: as network
speed grows, client-server separation will be less defined.
Inline.
"Baishampayan Ghose" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
>
> Heh, AJAX, as you might have noticed is mostly all buzzword crap, but
No. My experience is quite opposite: AJAX is very useful tool. Not more, not
less.
> again many not-so-knowledgeable developers wo
I pulled some of the info from this thread and started a Wiki page:
http://code.djangoproject.com/wiki/AJAX
Please commence filling in the blanks and correcting my errors and
misrepresentations :)
Baishampayan Ghose wrote:
> Yeah surely. I have discussed about this AJAX stuff at length on IRC and
> my preference is shared by a lot of people and has been posted on the
> list too. What I feel is that I know Django ``supports'' AJAX today
> itself in a way that it doesn't restrict / stop the u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eugene,
> 1) With all due respect I shall remind you that nobody forces to read all
> posts.
I know, but that's not the case. As you might realise, your one off
off-topic comments can stray the whole discussion towards something
which is totally irre
James Bennett wrote:
> For example, Rails includes an "AJAX library" called Prototype; this
> library provides "AJAX" functionality in that it delivers a facility
> for making asynchronous server calls from the client via JavaScript,
> but it also provides a number of easily-used visual DHTML eff
Baishampayan,
1) With all due respect I shall remind you that nobody forces to read all
posts.
2) I feel offended when people replace real issues with a stream of
meaningless buzz-words using evasive rhetoric when asked to explain the
meaning of those words --- "It depends on what the meaning
Today I discovered that I missed very interesting Django/Ajax-related
discussion on #django. Specifically MochiKit-Dojo comparison was discussed.
I know it is hard to talk about Dojo, when documentation is lacking. Let me
present my take, based on some experience with both toolkits from
prospe
>Remote scripting's been around, but GMaps and Garrett's >article
>whacked the mainstream designers over the head. AJAX >can stand for
>whatever acronym you want. When designers say "AJAX", >they mean rich
>interaction and a broken page request/response model >broken.
Actually AJAX can be done
On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Now I am confused. AJAX stands for Asynchronous JavaScript And XML. But
> "AJAX effects" == visual effects? You have to publish your own dictionary,
There's a disconnect between the code monkeys and the designers.
Remote scripting's bee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eugene,
[snip]
>>For example, Rails includes an "AJAX library" called Prototype; this
>>library provides "AJAX" functionality in that it delivers a facility
>>for making asynchronous server calls from the client via JavaScript,
>>but it also provides
Inline.
"Wilson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> I think Dojo looks great. Their rich text editor demo looks like it's
> designed to plug in to the Django admin :)
:) I am thinking to switch from TinyMCE to Dojo Rich Editor on my web sites.
> Before we get too f
Inline.
"James Bennett" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
>
>Many so-called "AJAX libraries" are as heavy on the "visual DHTML
"So-called" by whom?
>For example, Rails includes an "AJAX library" called Prototype; this
>library provides "AJAX" functionality in that it
I think Dojo looks great. Their rich text editor demo looks like it's
designed to plug in to the Django admin :)
Before we get too far into the "which Ajax framework should Django use"
discussion, I think it's important to lay the groundwork first.
It seems to me that the goal of any Ajax suppor
How about starting a wiki page (here's a good place to start:
http://code.djangoproject.com/wiki/AJAX ) as a place to collect
everyone's input on requirements, suggestions and examples.
There was some discussion in IRC today that it would be useful to
collect examples of how people are already us
On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> Now I am confused. AJAX stands for Asynchronous JavaScript And XML. But
> "AJAX effects" == visual effects?
Many so-called "AJAX libraries" are as heavy on the "visual DHTML
effects for use with AJAX" as on the actual meat of "AJAX" itself
Now I am confused. AJAX stands for Asynchronous JavaScript And XML. But
"AJAX effects" == visual effects? You have to publish your own dictionary,
man. Could you be more specific about drag-and-drop being a visual effect? I
was always thinking that it is much much more than that --- a functiona
On 11/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> What problem does this actually solve? Why do you care that people would
> use a bundled JS library? Should we also excise the template system from
> Django to avoid offending Kid? The ORM to avoid offending SQL object?
> What would be left?
On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> What are these mysterious "AJAX effects" you talking about in your posts? Is
> it the same as "AJAX in the core" or different beast?
As I mentioned in an earlier message, many "AJAX libraries" provide a
large stable of DHTML components whi
What are these mysterious "AJAX effects" you talking about in your posts? Is
it the same as "AJAX in the core" or different beast?
Thanks,
Eugene
"James Bennett" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
On 11/15/05, Robert Wittams <[EMAIL PROTECTED]>
wrote:
> What probl
hugo wrote:
> Hi,
>
>
>>So lets not pretend that there is zero cost to *not* picking something.
>>Users don't like uncertainty.
>
>
> I just don't see "bundle a JS library with Django" as anything that
> could be described as "add AJAX support to Django".
Yes, we can argue over terminology al
James Bennett wrote:
> As for the related topic of AJAX in the admin, I think the problem of
> "Django bundles an AJAX library, I should use that one" can be avoided
> with some care in how AJAX is used within Django; if only a particular
> subset of functions is needed, it may be possible to bund
Hi,
>So lets not pretend that there is zero cost to *not* picking something.
>Users don't like uncertainty.
I just don't see "bundle a JS library with Django" as anything that
could be described as "add AJAX support to Django". Sure, we can bundle
to our hearts content - and if there will be AJA
On 11/14/05, hugo <[EMAIL PROTECTED]> wrote:
> Actually the only thing I can think of that would be good if django had
> it, would be a REST style API to access model stuff that automatically
> will be returned in JSON format. That would allow JavaScript code to do
> easy database queries without
Lets make it happen. Who wants to be involved? What form of interaction is
preferred: IRC, e-mails, anything else?
AFAIK, Dojo is built on bones of many projects and directly sponsored by
real life applications like JotSpot (http://www.jot.com). Guys from WebWork
(http://www.opensymphony.com/w
...and of course typically there is a limit on how many items to be returned
for auto-suggest, but taking it into considiration ruins all fun of
arguments. :-)
"Jeremy Dunck" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
On 11/14/05, Maniac
<[EMAIL PROTECTED]> wrote:
> But I th
On 11/14/05, Maniac <[EMAIL PROTECTED]> wrote:
> But I think this whole approach is wrong and should not be supported.
> There are certain reasons behind separating server and client part and
> wishing to break this barrier smells like a bad design to me. If Django
> will make such things easy the
"Maniac" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> But I think this whole approach is wrong and should not be supported.
> There are certain reasons behind separating server and client part and
Care to share these reasons or provide a link to reasons you support?
Unfortun
hugo wrote:
> Hi,
>
>
>>Hence, I plead with the proponents of "Ajax support:" Please >show
>>concrete examples of what you want. Enlighten us.
>
>
> Actually the only thing I can think of that would be good if django had
> it, would be a REST style API to access model stuff that automatically
Adrian Holovaty wrote:
I've been using XMLHttpRequest for years now. My chicagocrime.org
site, powered by Django, uses Ajax in several places
(chicagocrime.org/map, for one). Django made this very easy. Yet I
still can't fathom what "Ajax support" at the server-side-framework
level *means*.
Hi,
>Hence, I plead with the proponents of "Ajax support:" Please >show
>concrete examples of what you want. Enlighten us.
Actually the only thing I can think of that would be good if django had
it, would be a REST style API to access model stuff that automatically
will be returned in JSON forma
Hi,
>I've been thinking about how Django might leverage DHTML^H^H^H^H^H
>AJAX a lot recently, and I think the framework I'll sketch out below
>should make a bunch of people happy.
my main gripe with your ideas is that you throw RPC style stuff
(XML-RPC and SOAP) in with the REST stuff. That just
"Robert Wittams" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> I have no idea where you are coming from. The fact that some stuff best
> performed with AJAX is wanted in the admin is clear (see ticket #13) . I
Yep. Just try to reorder stuff without drag and drop. I did it using
"Adrian Holovaty" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
>With that in mind, I still want to comprehend this mysterious concept
>of "Ajax support." In fact, I yearn for it. I want to know what it is,
>desparately.
Let me take a stub at it.
1) Client-side form validation.
2
James Bennett wrote:
> On 11/14/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
>>1) Let's keep different forums separate. I hope you responded to those
>>unnamed guys in the IRC channel.
>>2) My car has an integrated CD-player. Does it mean it is "in the core"? I
>>respectfully disagree with yo
Failing usability tests?
if stuff_is_blinking then return YOU_FAIL!!! :-)
"Jeremy Dunck" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
On 11/14/05, Eugene Lazutkin
<[EMAIL PROTECTED]> wrote:
>
> Nah, it would take all fun from bashing. :-) What kind of code do want to
> see for
I think this all sounds great. I also think Adrian's point in his post about AJAX support is very valid here. Any support for AJAX in Django should come from real needs in a real project.As Rob pointed out in an earlier thread, once the new-admin changes are rolled in, the project to fix the edit_i
Looks good. It pretty much consistent with my arguments. Unfortunately the
third layer is the most complex one and it is not well defined.
"Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
Hey folks --
Man, it's fun having such smart and passionate people on thi
On 11/14/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Nah, it would take all fun from bashing. :-) What kind of code do want to
> see for negative statements?
>
Failing tests.
On Nov 14, 2005, at 4:45 PM, Ian Holsman wrote:
I was also thinking of something a whole lot more simplistic as well.
javascript-enabling some of the validators.
I was planing on this being one of the web services views -- a
"validate" view that you would pass a new or modified object into
Nah, it would take all fun from bashing. :-) What kind of code do want to
see for negative statements?
"Simon Willison" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
>
>
> On 14 Nov 2005, at 22:37, Jacob Kaplan-Moss wrote:
>
>> How does this sound to everyone?
>
> Frickin' awesom
On 14 Nov 2005, at 22:37, Jacob Kaplan-Moss wrote:
How does this sound to everyone?
Frickin' awesome.
How about an informal rule for this list: no more discussion of Ajax
without code to back it up :)
Cheers,
Simon
I was also thinking of something a whole lot more simplistic as well.
javascript-enabling some of the validators.
for example.. we have a URL field.. it would be nice if the javascript
did the same regex match that the server side did, so that people
wouldn't have to submit it in the first place,
On Nov 14, 2005, at 4:34 PM, Adrian Holovaty wrote:
This is a good conversation, and I hope it continues.
Like ships passing in the night... :)
Jacob
Hey folks --
Man, it's fun having such smart and passionate people on this list!
I've been thinking about how Django might leverage DHTML^H^H^H^H^H
AJAX a lot recently, and I think the framework I'll sketch out below
should make a bunch of people happy.
As I see it, there are three layers
This is a good conversation, and I hope it continues.
Here are some thoughts, which I've brought up a number of times over
the past couple of months and remain unresolved.
Django is all about *actual tools that get actual stuff done* -- not
about buzz words, or academic noodling, or "let's make
Inline.
"James Bennett" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
On 11/14/05, Eugene Lazutkin
<[EMAIL PROTECTED]> wrote:
>By "AJAX in the core" I mean "Ships with an AJAX library and both
>makes use of that library in built-in areas and exposes an interface
>for the use of
On 11/14/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> 1) Let's keep different forums separate. I hope you responded to those
> unnamed guys in the IRC channel.
> 2) My car has an integrated CD-player. Does it mean it is "in the core"? I
> respectfully disagree with your definition of "in the c
On 14 Nov 2005, at 21:30, Eugene Lazutkin wrote:
I would be happy, if Django supports many libraries, but I don't
think we
can afford it. E.g., I can understand the need for 2 versions of
Admin:
plain vanilla HTML, and Ajax version. If somebody wants to create 3rd
version of Admin, it is f
Inline.
"James Bennett" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
On 11/14/05, Eugene Lazutkin
<[EMAIL PROTECTED]> wrote:
>> I don't recall anybody proposing "AJAX in the core".
>I've seen it asked for more than once, particularly in the IRC
>channel. People ask for Django
On 14 Nov 2005, at 19:26, Eugene Lazutkin wrote:
I think it is wise to talk to core Dojo guys (e.g., Alex Russell)
about
Django Ajax and explain them what we need. They are accessible and
responsive. I am sure they will meet Django's requirements. Let's
talk to
Bob too to understand his p
I agree with keeping the quality high. There are a few other decent
frameworks out there, but has a lot of people using it who don't really
have to think and just because of that community it turns me off of the
framework.
My example regarding the partner was a situation where the partner is
On 11/14/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> I don't recall anybody proposing "AJAX in the core".
I've seen it asked for more than once, particularly in the IRC
channel. People ask for Django to pick one AJAX library and integrate
it. To me, that's "AJAX in the core".
> While Ajax i
I don't recall anybody proposing "AJAX in the core". Clearly Ajax should be
an optional feature. While Ajax is generating a lot of buzz lately causing
adverse reaction in non-marketing people, don't overlook it is potential to
improve usability of web sites. Ajax can be abused, but let's be pra
Personally I am leaning towards Dojo over MochiKit.
Disclaimer: I contributed some code to Dojo so I may be biased. Upside: I
know what I am talking about in regards of Dojo.
The reasons are simple: flexible AOP-inspired event system, thought-out
widget packaging and management, versatile I/O.
On 11/14/05, Stephen Rainey <[EMAIL PROTECTED]> wrote:
> I agree with you that it's pure marketing fluff and I guess you see that
> was my point. It just got me to thinking when I was reading about
> developer adoption. I do like your lightweight ideas. It might be good
> to do something rather l
I agree with you that it's pure marketing fluff and I guess you see that
was my point. It just got me to thinking when I was reading about
developer adoption. I do like your lightweight ideas. It might be good
to do something rather lightweight and then get some visibility on the
website abo
Simon Willison wrote:
>
>
> On 14 Nov 2005, at 07:10, swrainey wrote:
>
>> Ajax is really hot right now and I could see loosing some developers
>> because it's not as on the forefront of the whole web 2.0 hyped up
>> junk. Ajax is more about usability than eye candy or at least it should
>> be
On 11/14/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> For me "Ajax support" really is pure marketing fluff - as far as I'm
> concerned EVERY web framework supports Ajax unless it does something
> truly moronic like refuse to let you output documents that don't have
> the standard header/footer
On 14 Nov 2005, at 07:10, swrainey wrote:
Ajax is really hot right now and I could see loosing some developers
because it's not as on the forefront of the whole web 2.0 hyped up
junk. Ajax is more about usability than eye candy or at least it
should
be. That being said. I know I can use aja
I'm a developer trying to choose what framework to use. I would like to
give my perspective on the situation. I would personally like to see
0.9 released real soon with a roadmap of what is coming for the 1.0
release and what might not be backwards compatible. I can easily see
that this framework
"Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> Reading over what I've written so far, it seems that I'm shying away from
> difficult tasks. Perhaps I am, but the fact is that the longer we linger
> in a pre-release stage the more our potential community
+1 for hugo's suggestion. A tarball now gives us a "stable" version to point people to before we start knocking off backwards-incompatible changes. A finalized roadmap for 1.0 puts the target in sight. And 0.9 says "we're almost there". All in favor
On 11/9/05, Jeremy Dunck <[EMAIL PROTECTED]> wrot
> If
> we decide that these features can't be done in a backwards-compatible
> way and have to release a 2.0 six months after 1.0, what's the harm in
> that?
>
Thats fine, but that needs to be made absolutely clear. The default that
people are going to expect is that we are "satisfied" with t
Adrian Holovaty wrote:
> On 11/9/05, hugo <[EMAIL PROTECTED]> wrote:
>
>>I would say: release a 0.9 version now (or in the near future) and give
>>a clear roadmap (that's what the trac feature is for ;-) ) of what will
>>go into 1.0 before release. That way people have some "quite stable
>>but n
On Nov 8, 2005, at 3:41 PM, Robert Wittams wrote:
Ok, so this generated quite a bit of traffic.
Ha -- thanks for kicking this off; it needed to be discussed.
I *really* don't think that 1.0 should be considered on the basis of
stability and usability of the implementation. It should be on
On 11/9/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 11/9/05, hugo <[EMAIL PROTECTED]> wrote:
> > I would say: release a 0.9 version now (or in the near future) and give
> > a clear roadmap (that's what the trac feature is for ;-) ) of what will
> > go into 1.0 before release. That way pe
On 11/9/05, hugo <[EMAIL PROTECTED]> wrote:
> I would say: release a 0.9 version now (or in the near future) and give
> a clear roadmap (that's what the trac feature is for ;-) ) of what will
> go into 1.0 before release. That way people have some "quite stable
> but not 1.0" tarball to play with
>I have no idea why we have to marry the idea of releasing a tarball to
>the number 1.0, but the number 1.0 is already explicitly married to
>backwards compatibility in the eyes of most users. IMO there are still a
>number of areas that need a fair amount of work.
I would say: release a 0.9 versi
>I also don't like #251 that much, but I'd take it over the >scary
>undocumented "_or" we've got now (and over raw SQL, >which sucks).
How about another solution to expression combination: wrapping query
expressions (the field__exact and friends) optionally in Query()
objects that implement __or_
Jacob Kaplan-Moss wrote:
>
> On Nov 8, 2005, at 10:13 AM, Adrian Holovaty wrote:
>
>> On 11/8/05, Robert Wittams
>> <[EMAIL PROTECTED]> wrote:
>>
>>> The general feeling from those using or considering Django (including
>>> some rubyists) seemed to be "Release a 0.7 tarball, for the love of all
personally I'd like to see the user-registration app get
documented/released as well.
what is the state of this?
On 11/9/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Inline.
>
> "Adrian Holovaty" <[EMAIL PROTECTED]> wrote
> in message
> news:[EMAIL PROTECTED]
>
> On 11/8/05, Jacob Kaplan-Mos
Jacob Kaplan-Moss wrote:
So, any objections to starting a 1.0 bug-fix-only release branch?
No objection but a concern...
Some time ago I filed a ticket
(http://code.djangoproject.com/ticket/570/) about FormWrapper not
working for ForeignKey fields. It's rather basic functionality and I
co
Inline.
"Adrian Holovaty" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
On 11/8/05, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * Transactions.
There are problems with transactions in caching --- sometimes database is
locked up for no reason without any errors. I didn't hav
On 11/8/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> * Screencasts so fucking exciting you'll cry.
I'll stock up on gatorade.
On 11/8/05, Pedro Furtado <[EMAIL PROTECTED]> wrote:
> Don`t you agree this is an imprescindible
> update?
I dunno what imprescindible means. :)
# Why don`t we include Django-Ajax in 1.0? I agree that releasing it
# sooner is good for the project but a nice ajax interface is the
# future for all web applications. Don`t you agree this is an
# imprescindible update?
I think that really goes into the "bells and whistles" category.
Admittedly
On Nov 8, 2005, at 11:30 AM, Adrian Holovaty wrote:
I'd like to see a solution to "core=True" before 1.0 -- i.e., not
having to use that anymore. This goes beyond what new-admin offers,
and it would probably be a backwards-incompatible change (hence the
1.0 requirement).
That's a good point --
2005/11/8, Adrian Holovaty <[EMAIL PROTECTED]>:
>
> * RSS
> * Comments framework
> * Authentication (already started; I need to finish)
> * Admin-site documentation (already started on my laptop; I need to finish)
> * Views (already started on my laptop; I need to finish)
> * Finish tutorial
> * H
On 11/8/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> What's the state of this branch? Last time I tried it out -- a few
> weeks ago, IIRC -- there seemed to be a bunch more work to be done.
> I'd obviously LOVE to see this get rolled in, but if it's a "few
> months" thing I don't think it w
On Nov 8, 2005, at 11:08 AM, Adrian Holovaty wrote:
Here's what we should finish before this first 1.0 version:
* Transactions.
Agreed.
* New-admin branch.
What's the state of this branch? Last time I tried it out -- a few
weeks ago, IIRC -- there seemed to be a bunch more work to be d
I got to say that I really think what adrian says is the right thing to
do. Get the docs done, and merge the new-admin got to be top priority
in my opinion.
On 11/8/05, Eric Walstad <[EMAIL PROTECTED]> wrote:
>
> On Tuesday 08 November 2005 08:35, Jacob Kaplan-Moss wrote:
> > I think we need to bite our lips, suck it up, and release a 1.0
> > version.
>
> +1
>
> A "stable" release would make those who are trusting my judgement in
> choosing Django for
On 11/8/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> If it sounds OK, I'd like to start a 1.0 release branch and only
> apply any outstanding bug fixes to it; moving feature requests/
> patches to a 1.1 target. That way we can get a stable 1.0 out the
> door and focus on 1.1 for feature imp
On Tuesday 08 November 2005 08:35, Jacob Kaplan-Moss wrote:
> I think we need to bite our lips, suck it up, and release a 1.0
> version.
+1
A "stable" release would make those who are trusting my judgement in
choosing Django for a medium-large-ish project a little less nervous
(me, too).
On Nov 8, 2005, at 10:13 AM, Adrian Holovaty wrote:
On 11/8/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
The general feeling from those using or considering Django (including
some rubyists) seemed to be "Release a 0.7 tarball, for the love
of all
that is holy!"
It seems that quite some peo
On 11/8/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> The general feeling from those using or considering Django (including
> some rubyists) seemed to be "Release a 0.7 tarball, for the love of all
> that is holy!"
>
> It seems that quite some people just aren't comfortable with checking
> thing
So I went to the London Django/Rails meetup yesterday. In general a good
time was had - met Simon Willison, and some ThoughtWorks guys doing a
GreenPeace site with Django.
The general feeling from those using or considering Django (including
some rubyists) seemed to be "Release a 0.7 tarball, for
89 matches
Mail list logo
