that we can avoid having more folks as
frustrated as me.
--
Berin Loritsch
Owner
Work:
571-215-7708
---BeginMessage---
I am beyond frustrated with trying to adapt the CForms upload feature to
our application. I have about two hours left for today, and I'd like to
get it working, but if I can't I will resort to the traditional method
of forms and actions.
Please, if you have bandwidth to
: 2.1.8
Reporter: Berin Loritsch
Priority: Critical
JEXL will not allow you to access cocoon.request or cocoon.session and company
unless a flowscript performs a sendPage related request. This violates the
principle of least surprise, and caused over four hours of productivity loss
just
I submitted bug COCOON-1816 because the cocoon object model was not set
up in a way that I expected. It cost hours of lost productivity only to
find out I have to bounce my processing for a static page (with a couple
variable pieces) through a flowscript just to access cocoon.request. To
me
I have a Java object I am using to generate links. It would make my
life easier if I could use it directly in my XSLT--even though it is
created outside of the XSLT system. Is it as easy as passing it in as a
parameter? Or is there some extra leg work necessary?
Niklas Therning wrote:
Carsten Ziegeler wrote:
Yes, please :) I would suggest log4j as commons-logging has problems
with classloading (afair) and noone is using jdk14 logging.
Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's
a facade for other logging frameworks but it
Stefan Pietschmann wrote:
What is the benefit of declaring custom roles in a user-role file
outside cocoon.xconf, if you can do it together with the configuration
inside cocoon.xconf? Is there any? I don't see the point …
Stefan
It helps with conciseness in the cocoon.xconf.
For
Carsten Ziegeler wrote:
Ok, perhaps the code isn't that bad...now, both methods
(getGlobalBaseDatas and getGlobalDatas) are synchronized, so only one
thread can enter them and therefore only one thread can change the
corresponding objects. At the end of the method, the map is returned and
this
Vadim Gritsenko wrote:
Berin Loritsch wrote:
Daniel Fagerstrom wrote:
Decomponentization could start right away. Do you have any
concrete examples of components that shouldn't be components?
Pipeline (sure we have two implementations, but that doesn't mean it
has to be a component
Vadim Gritsenko wrote:
URL interpretation
?
SourceResolver and company
It proved to be very valuable extension point
I'm not negating that, however the way it is currently implemented makes
it difficult to use at times. Again there are different ways of
skinning this particular
Jorg Heymans wrote:
OK, so unless someone vetoes this the next few hours i will start
shifting files about around 11pm CET today.
It would be great if people could refrain from checking stuff into
trunk/core from then onwards until i've finished. It will take a good
few hours, i'll notify when
Much has been talked about in regards to the component infrastructure.
That's a good thing, but after years of component based design, and
getting back to the roots of just plain old object oriented design, I
have to question why everything needs to be a component. Using good
OOD, we can
Daniel Fagerstrom wrote:
Berin Loritsch skrev:
...
Much like Photoshop with filter plugins. The block idea would be
more analagous to complex macros for Photoshop. They may provide new
plugins to use in the package, but they allow you to do predefined
things.
I don't know enough about
Sylvain Wallez wrote:
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
This is a huge
Torsten Curdt wrote:
On 30.12.2005, at 20:21, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface
Vadim Gritsenko wrote:
Ralph Goers wrote:
Also, Do you know why Document helper is declared static?
DocumentHelper *class* is static. Why it should not be?
Is DocumentHelper an inner class? If so I agree, all that the static on
a class means is that the inner class can (should?) be in
Ralph Goers wrote:
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
As far as pools go, I feel like a complete idiot. See my comments below.
Vadim Gritsenko wrote:
Ralph Goers wrote:
Thanks Vadim. I'm posting this back to the Cocoon
Vadim Gritsenko wrote:
Ralph Goers wrote:
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
It's *good*. You don't really want several threads trying to load
*same* document.
It's not perfect though. I see that XMLFileModule, when
http://headrush.typepad.com/photos/uncategorized/kickasscurve_1.jpg
I say we take the chart, superimpose the Cocoon versions over it and
make it happen. Don't we want to reduce the time it takes users to
kickass?
The article it came from is located here:
IMO, abstraction is not bad, however the wrong abstraction is. Using
the right abstraction can make using a library or tool much easier to
grasp and use.
Now, I'm sure you are sick of Ruby and Rails, but I'd like to share a
little about how the user interacts with the environment there. It
Vadim Gritsenko wrote:
Niclas Hedhman wrote:
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote:
For the versioning, we could for example release a 2.2 soon, change the
environment abstract after that and then release a 2.3 later this year.
Two more releases this year, YEAH!!!
Carsten Ziegeler wrote:
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem. Anyways, our current Request object has more
functionality as the servlet request object, e.g. to get the sitemap
Gianugo Rabellino wrote:
On 12/13/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
I agree that the main focus must be to get a 2.2 release. So the
question is what to do with the real blocks. They are currently rather
close to the specification, but we don't know if the specification is
good
On Wednesday December 07, 2005 6:26 pm, Thomas Lutz wrote:
Though I am not a dev guy, I can't resist to vote, too. IMHO a mix makes
no sense. Too make a long story short I made struggled my way into
cocoon with
snip type=everything I was feeling, and I'm not alone in my view/
Last comment:
Upayavira wrote:
Matthew Langham wrote:
I really think the current discussions on CocoonReloaded could do with some
higher bandwidth talks to formulate a first plan. How many Cocoonites will
be at ApacheCon and could perhaps get together? I won't be there but Carsten
is (for example).
In the exchange below I did some creative snipping to emphasize where we
are not 100% aligned on vision. Below I will bring out my points,
knowing that I'm not the guy who sets the tone for Cocoon.
Torsten Curdt wrote:
Berin:
... I envision a Cocoon which takes its principle strengths in
Berin Loritsch wrote:
What's your preference for the vision?
[ ] All web apps written in JavaScript
[X] All web apps written in pure Java
[ ] Mix and match (not as simple, but is status quo with today)
hepabolu wrote:
Berin Loritsch wrote:
What's your preference for the vision?
[ ] All web apps written in JavaScript
[ ] All web apps written in pure Java
[X] Mix and match (not as simple, but is status quo with today)
With Ajax and other bells and whistles on the client side
Ralph Goers wrote:
None of these. I have a vision where the business services are
implemented in Java, the web application is defined in a stateful flow
controller (xml config) and the views are generated using pipelines
with standard components. So my answer is - No programming language
Ross Gardler wrote:
Berin Loritsch wrote:
I would argue that what you are talking about is a domain specific
language in the guise of configuration (just like your hibernate
descriptors and ant scripts).
Sometimes, DSL's bring many benefits, just consider the sitemap.
Do we want to know
So far it seems as if we are looking at two options: Pure Java or
status quo. And so far we are something along the lines of 2 for Java
and 2 (possibly 3) for status quo.
Anyone else have input?
Ugo Cei wrote:
Il giorno 07/dic/05, alle ore 15:23, Berin Loritsch ha scritto:
What's your
Ugo Cei wrote:
Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto:
Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much
better. No chance that it could be released without renaming.
Hmmm ... maybe Cocoon 360? ;-)
No, CS3 implemented on the cell processor ;P
Aurélien DEHAY wrote:
Hello.
Sorry for the intervention of a non-dev on the dev list, but shouldn't
this question be asked on the user mailing list?
:) Yes and no. Check this article out for more information:
Daniel Fagerstrom wrote:
To me:
* throwing away the collected work of the community
* building something rather different
* throwing away a strong brand
* leave all the users who has put a trust in us behind
seem like a rather strange way of saving Cocoon.
It seemed like a rather strange
Daniel Fagerstrom wrote:
Berin Loritsch wrote:
I will continue to be proud of our brand, our product and our
community. And I will continue the work on *Cocoon* towards the
future in an evolutionary way, so that those who have put their
trust in us have a reasonable migration path to follow
In all the talks of redesign or not, there has been a recurring question
as to the vision. Sylvain has outlined some things that he would like
to see, but they really don't constitute a vision. They are a nice list
of improvements, but they aren't a vision. In my experience the best
visions
Upayavira wrote:
I've been thinking more about Sylvain's proposal and ideas. And would
like to suggest a way to look at it and see how it fits into the context
of what we already have.
Sylvain is proposing something different, something that is likely to be
almost entirely incompatible with
I'm not going to take too long, but this is just anecdotal evidence of
why I think Cocoon 2 is stagnating and we really need a Cocoon 3. Let's
roll back the calendar just a couple short months ago just before the
Cocoon Get Together.
I proposed a change to the way Cocoon would process a
hepabolu wrote:
More important I think is not only defining the vision of Cocoon 3.0
as precisely as possible (so all jumping up and down now, know exactly
where to jump in), and coming up with a roadmap, but also to try and
define/write conversion tools (however simple) almost from the
Here is a wonderful article at Creating Passionate Users:
http://headrush.typepad.com/creating_passionate_users/2005/09/listening_to_us.html
There are many things we can learn from this site--its fun, and it
challenges the status quo. If we are going to rock the boat a bit, we
need to take
On Sunday December 04, 2005 2:49 pm, Joerg Heinicke wrote:
On 03.12.2005 05:58, Berin Loritsch wrote:
Why is Ruby on Rails fun to work with? It is because
things make sense. You only need to learn Ruby to be able to create a
useful website. You don't need to learn Sitemap Markup Language
If Cocoon goes for a 3.0 approach, I would have to argue for a more
radical approach than just fix things here and there. The problem is
one of focus. On paper Cocoon is a very capable framework. It
introduced us to a great new world of dynamic web sites. It's caching
system kicks tousche.
If Cocoon goes for a 3.0 approach, I would have to argue for a more
radical approach than just fix things here and there. The problem is
one of focus. On paper Cocoon is a very capable framework. It
introduced us to a great new world of dynamic web sites. It's caching
system kicks tousche.
Sylvain Wallez wrote:
Berin Loritsch wrote:
There are two antipatterns that I see with Cocoon as a whole (from
the current design aspect): Alphabet soup syndrome, and mixed
metaphors. The alphabet soup syndrome has to do with the fact that
we are buzzword compliant without really taking
Max Pfingsthorn wrote:
Hi!
I've had a bit of trouble with components that are not referenced by others. I
need to start (i.e. service, configure, initialize, etc) a component once the
container is started. Can I do this somehow?
I noticed an attribute called activation (next to logger) which
Sylvain Wallez wrote:
Hi all,
For many years, I have been more than happy with Cocoon, enjoying the
power and ease it brought for both publication and webapp projects.
Over the last months however, other feelings have emerged: there are
things that are definitely overly complex in Cocoon,
In the period of about 12 hours there has been over 120 messages generated by
JIRA. All to do with opening and closing issues, etc.
While it is to be expected that the introduction of the new tool is going to
require some rampup time, Its hard to see the real mail traffic.
Is there any way to
On Tuesday 25 October 2005 10:18 am, hepabolu wrote:
Berin Loritsch wrote:
In the period of about 12 hours there has been over 120 messages
generated by JIRA. All to do with opening and closing issues, etc.
While it is to be expected that the introduction of the new tool is going
Ralph Goers wrote:
The code freeze for the 2.1.8 release starts tonight and ends next
friday (hopefully) with the release of 2.1.8.
The usual committing rules for a code freeze apply.
We're on subversion right?
What's wrong with creating a branch for 2.1.8 release candidate and
finishing
Mark Lundquist wrote:
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only
their original creators) are using it.
I never really did get Apples. Can somebody just sort of give a
quick summary of what it's all about, and why
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
I think a long time ago we decided to remove the author tags, upto now
nothing really happend :(
Yep. There was a positive vote (probably more than one actually), and
since then nobody adds new @author tags, meaning the information is
Torsten Curdt wrote:
What has stopped us is that we need to keep a track of these to give
credit. And also show to the world the incredibly large developer
group we are :-)
But if you give credit without a connection to parts of the code it's
just a list of the committers (more or less)
The Processor interface used to be very simple, and reasonably
documented. Over time it has adopted new methods as part of its
contract, and those have not been well documented. The only reason that
I am bringing this up is that I am trying to implement my own Processor,
and there is a lot
Based on the calls from the whole of Cocoon, the core Processor
Interface is:
interface Processor
{
InternalPipelineDescription buildPipeline(Environment env);
boolean process(Environment env);
}
(Note: I would separate out the InternalPipelineDescription object into
its own class)
Carsten Ziegeler wrote:
As a short answer: yes, the interface is ugly - but on the other hand we
only have one implementation and could remove the interface and directly
interact with the tree processor :)
The reason is more or less a historical one. We needed a clean
implementation for the
Carsten Ziegeler wrote:
Berin Loritsch wrote:
The only thing that needs the getComponentConfigurations() method is the
DefaultSitemapConfigurationHolder.
We need a new interface to support that contract. Not all processors
need to use that.
Actually the current
In this thread, we have the perfect example both of what makes Cocoon
great and its own achiles heel. The initial proposal here was to make a
new type of sitemap that mimics the Ruby on Rails pattern of Convention
over Configuration. It even had some nice approaches to flexing some of
Max Pfingsthorn wrote:
snip type=a bunch of implementation stuff/
The handleControllerCall function can be written in flowscript or even use
the great new java flow as shown by Torsten Curdt during the get together. Not sure how
that class reloading works, but if you put the controller
Upayavira wrote:
[EMAIL PROTECTED] wrote:
Author: bloritsch
Date: Mon Oct 10 12:56:04 2005
New Revision: 312725
URL: http://svn.apache.org/viewcvs?rev=312725view=rev
Log:
starting to flesh out my ideas--they are better seen rather than
discussed
Added:
cocoon/blocks/crails/
Upayavira wrote:
Berin Loritsch wrote:
Where is whiteboard?
https://svn.apache.org/repos/asf/cocoon/whiteboard/
Create yourself a directory there.
Will do.
SHRT = Semi-Humorous Random Thought
Here's the deal: Cocoon is a very powerful publishing framework adapted
to do web applications, and Ruby on Rails is a very empowering web
application framework that can be adapted for a number of purposes.
There are two very different mindsets behind the
Andrew Savory wrote:
Hi Berin,
On 7 Oct 2005, at 15:09, Berin Loritsch wrote:
Here's the deal: Cocoon is a very powerful publishing framework
adapted to do web applications, and Ruby on Rails is a very
empowering web application framework that can be adapted for a
number of purposes
Andrew Savory wrote:
In all seriousness, the biggest lesson from the Ruby on Rails
project that Cocoon can learn is the power of convention. One of
the biggest things that contributes to the high learning curve of
Cocoon is the lack of convention.
Not just the lack of convention but
Using ESQL against MSSQL Server, any NTEXT or NVARCHAR are incorrectly
re-encoded to ISO 8859.
Directly using the driver yields the correct results.
hepabolu wrote:
Berin Loritsch wrote:
hepabolu wrote:
Guys,
I feel that Daisy should be the source for all documentation about
Cocoon (at least for now), so I'll be copying over the reference
documentation of all sitemap components, as they are currently
defined in the Javadocs
Sylvain Wallez wrote:
Kewl! If it's based on the 2.2 branch, you may reduce startup time by
adding JAVA_OPTIONS=-Dorg.apache.cocoon.core.LazyMode=true in the
launch script (BTW, should we make this the default?)
IMO Yes. Anything that helps us work more efficiently should be default.
Sylvain Wallez wrote:
Interesting question. If we ship with dev mode on, many people will
deploy in dev mode. On the other hand, if we ship in production mode,
many people won't see the features of dev mode.
A solution is to ship in dev mode, but ensure that people know they're
in dev
Bertrand Delacretaz wrote:
Le 3 oct. 05, à 22:56, Mark Lundquist a écrit :
...But please don't use the term close down, instead say merge or
consolidate :-)
You're right, of course, merge is much more appropriate.
-Bertrand
Before going too far with this proposal, consider the impact of
Reinhard Poetz wrote:
Out of curiousity, is there any special reason not to take the
UnsupportedOperationException instead?
Not a major one. Precedence has already been set in another part of the
Cocoon code base, so I carried it forward. There is also a distinction
between something
FYI:
I changed the FIXME comment that had a question with a runtime
exception. This should answer the question quite well. Before we
simply ignored XMLBundles with no base URL--now we force the system to
deal with it. It should also help tighten up some code.
[EMAIL PROTECTED] wrote:
Torsten Curdt wrote:
/Users/tcurdt/dev/cocoon-trunk/src/java/org/apache/cocoon/generation/
RequestGenerator.java:233: cannot resolve symbol
symbol : class RequestParseException
location: class org.apache.cocoon.generation.RequestGenerator
throw new RequestParseException(Could not
Very interesting read. As with all inovations, the greatest
achievements are usually the side issues. The SoC, component
frameworks, et al, helped improve the way we think about approaching the
development of software. While that has little to do with web
publication, the contributions to
Antonio Gallardo wrote:
Hi:
Here is the output:
Compiling 330 source files to
/home/agallardo/svn/cocoon-2.1/build/cocoon-2.1.8-dev/blocks/forms/dest
/home/agallardo/svn/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/library/Library.java:118:
cannot resolve symbol
Antonio Gallardo wrote:
Ralph Goers wrote:
I guess this means forms trunk has to support JDK 1.3 and cannot move
to 1.4?
Yep, since we are now sharing the same form block (in cocoon-blocks)
for both cocoon versions (2.1.x and 2.2).
Seems like every day JDK 1.3 compatibility becomes a
Based on the errors from the Java 1.3 compatability issues I decided to
check how pervasive the use of generic runtime exceptions was. I am
quite surprised at the results. It seems that instead of having planned
and known exceptions we opt to throw generic exceptions all over the
place.
I can't seem to reference a graphic in my FO document to be included in
my PDF document.
The problem is that the graphic is generated on the fly--and only really
accessible through a
cocoon URL. I can't seem to make it work, and I can't seem to find
any documentation to
help me on my way.
Torsten Curdt wrote:
On 06.09.2005, at 04:23, Antonio Gallardo wrote:
Hi:
Recently on excalibur dev I found that most (if not all) the code in
excalibur-io was moved to commons-io:
http://www.mail-archive.com/dev%40excalibur.apache.org/msg01599.html
Cocoon 2.1.x has only 3 references
http://cocoon.zones.apache.org/daisy/documentation/writing/sitemapcomponents/694.html
Really simple transformer example as most people aren't going to write
their own transformers anyway.
Sylvain, since you provided the source information, can you make sure I
didn't interject anything wrong? The URL for the writeup is here:
http://cocoon.zones.apache.org/daisy/documentation/writing/690.html
I have yet to work on the transformer component, but we almost have the
full gammut
Sent to the wrong mail list... sorry
---BeginMessage---
Sylvain, since you provided the source information, can you make sure I
didn't interject anything wrong? The URL for the writeup is here:
http://cocoon.zones.apache.org/daisy/documentation/writing/690.html
I have yet to work on the
Carsten Ziegeler wrote:
Berin Loritsch wrote:
Anybody know what the root issue is?
The type attribute of the pipeline element has not been evaluated
correctly. In this case the type attribute of the first pipeline element
has been used for all pipeline elements in a sitemap.
Do
This is one that I think could use a second pair of eyes to make it more
understandable. The URL is here:
http://cocoon.zones.apache.org/daisy/documentation/writing/sitemapcomponents/688.html
I also had to introduce the XML Pipeline contracts documentation here:
Alot of the information I documented really should have been part of the
JavaDocs all along. I took the liberty of adapting what I wrote on
daisy to the JavaDoc format. Even though there is a large amount of
duplication now between the two resources, I still think that there is
value in the
Tony Collen wrote:
Berin Loritsch wrote:
This will be my last installment before I go on vacation next week.
The earliest I can get to the Generator, Transformer, and Serializer
components will be after Sept. 5. Enjoy
+1, excellent writeup!!! Very good quality.. keep it up
How to Create a Reader:
http://cocoon.zones.apache.org/daisy/documentation/components/sitemapcomponents/681.html
I hope others proof what I've written because it is largely based on a
combination of memory and implementation details as I update my knowlege
base. I want to make sure I'm not
Emmanouil Batsis wrote:
On Friday 19 August 2005 18:01, Upayavira wrote:
Do you have a hosted linux server anywhere? Log onto that, do a
checkout, make your zip (even build Cocoon with just the blocks you
want) zip up whatever is left and download it.
Unfortunately the server does
Sylvain Wallez wrote:
Hi all,
I just committed the Cocoon stacktraces stuff to trunk.
There's some more work to be done to throw located exceptions
everywhere and reduce exception nesting, but the basic infrastructure
is there and is really an improvement compared to what we had a few
http://cocoon.zones.apache.org/daisy/documentation/components/664.html
Please note that I am still working on stuff there, but I am taking a
break for today. I wanted to cover the really basic root level stuff
first so that it is easier to reference that when I get to the higher
level
I've got the core contracts for the sitemap documented (need some sanity
checking there), and documentation for creating a simple Action up and
ready for review. You can view it here:
http://cocoon.zones.apache.org/daisy/documentation/components/664.html
I'm going to have to take a break
Steven Noels wrote:
On 13 Aug 2005, at 23:15, Berin Loritsch wrote:
It's not that hard to write the Cocoon components, but there should
be something that puts it down. I can't guarantee I can do it soon
but I'll see what I can do. Where should I put it in the grand
scheme of things
I can't add anything or create a new area for documentation. That means
all I can do is view. Kind of hard to contribute like that.
Upayavira wrote:
Berin Loritsch wrote:
I can't add anything or create a new area for documentation. That
means all I can do is view. Kind of hard to contribute like that.
As you are down as an (emeritus) cocoon commmitter, I've just given
you rights.
Look forward to seeing the results
It seems that a huge hole in documentation exists on the site. As I was
training one of my crew on how to write a reader (adapting a servlet we
had) I found I couldn't refer to one nice page. Not even the JavaDocs
really help all that much. I didn't even know about the
ObjectModelHelper
It seems that a huge hole in documentation exists on the site. As I was
training one of my crew on how to write a reader (adapting a servlet we
had) I found I couldn't refer to one nice page. Not even the JavaDocs
really help all that much. I didn't even know about the
ObjectModelHelper
On Wed, 2005-08-10 at 15:55 +0200, Leszek Gawron wrote:
Berin Loritsch wrote:
Considering we have a very international user base, and the fact that
more and more projects have to deal with international or special
character, why not make the demo international friendly.
In order to set
Considering we have a very international user base, and the fact that
more and more projects have to deal with international or special
character, why not make the demo international friendly.
In order to set encoding standards for your mime-type you have to
include the character-encoding after
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Gregor J. Rothfuss wrote:
Leszek Gawron wrote:
Berin Loritsch wrote:
In order to set encoding standards for your mime-type you have to
include the character-encoding after the mime-type. Ex:
text/html;encoding=utf-8
You probably mean
Carlos M. S. Bento Nogueira wrote:
Hi. Just couldn't agree with your suggestion as Spanish and Portuguese
characters(for example �,�,�,� ) aren't supported by utf-8. But this
is just my opinion...
You mean like: ñðòóôõö
The Spanish and Portuguese characters probably have a different value
Niclas Hedhman wrote:
On Wednesday 10 August 2005 21:43, Berin Loritsch wrote:
Considering we have a very international user base, and the fact that
more and more projects have to deal with international or special
character, why not make the demo international friendly.
The most
Antonio Gallardo wrote:
BTW, Spanish and Portuguese characters(for example ç,à,á,ñ ) aren't
supported by utf-8.
UTF-16 values are:
ç = 00e7
à = 00e0
á = 00e1
ñ = 00f1
For UTF-8 there would be some multibyte representations of them because
they are above 0080.
Its detailed by this page:
1 - 100 of 312 matches
Mail list logo
