You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Mohamad Mataram Purbo <pu...@apas.co.jp> on 2000/04/06 09:37:05 UTC

Cocoon for Japanese Mobile Phone

Dear All,

I'm writing experimental 'portal' site for Japanese web-enabled mobile phone
(as you might all aware that there are already 10 million mobile-web-user
here with billions page-view a day in total).

There are 3 major players in Japanese mobile market:
1. NTT DoCoMo (about 60% market share), using CHTML, with about 7000
content-provider CHTML specific.
2. IDO (20% market share), using HDML, (i don't know the figure, but i guess
some hundreds)
3. J-Phone (20% market share), using MML, more than 100 of content-provider
MML-specific

All of these systems can access HTML content with many limitations.

I'm trying Cocoon to serve to all of these types of web-device.
My problem is,

Not all of the mobile-client agent sends user-Agent information on HTTP
header, so I cannot use Cocoon mechanism to recognize these client. But they
do sends some specific information in the HTTP header to identified
themselves.

for example,
J-SH02 (latest model of Sharp for J-Phone with 256 color display) sends
these
information in the header:
x-jphone-display=96*98
x-jphone-color=256
x-jphone-name=J-SH02
etc etc...

To resolve this problem, i'm thinking of preprocessing the http header info
before passing the request to cocoon.

Well, anyway i cannot think of any 'clean' and 'elegant' solution for this
problem. Just wondering whether one day Cocoon will has customized way to
recognize user agent.

Does anybody has idea about this?

Anyway, thank you to the creator, for this great product.

Best Regards,

M. Purbo
APAS, Inc.
Japan






Re: Cocoon for Japanese Mobile Phone

Posted by Stefano Mazzocchi <st...@apache.org>.
Mohamad Mataram Purbo wrote:
> 
> Dear All,
> 
> I'm writing experimental 'portal' site for Japanese web-enabled mobile phone
> (as you might all aware that there are already 10 million mobile-web-user
> here with billions page-view a day in total).
> 
> There are 3 major players in Japanese mobile market:
> 1. NTT DoCoMo (about 60% market share), using CHTML, with about 7000
> content-provider CHTML specific.
> 2. IDO (20% market share), using HDML, (i don't know the figure, but i guess
> some hundreds)
> 3. J-Phone (20% market share), using MML, more than 100 of content-provider
> MML-specific
> 
> All of these systems can access HTML content with many limitations.
> 
> I'm trying Cocoon to serve to all of these types of web-device.
> My problem is,
> 
> Not all of the mobile-client agent sends user-Agent information on HTTP
> header, so I cannot use Cocoon mechanism to recognize these client. But they
> do sends some specific information in the HTTP header to identified
> themselves.
> 
> for example,
> J-SH02 (latest model of Sharp for J-Phone with 256 color display) sends
> these
> information in the header:
> x-jphone-display=96*98
> x-jphone-color=256
> x-jphone-name=J-SH02
> etc etc...
> 
> To resolve this problem, i'm thinking of preprocessing the http header info
> before passing the request to cocoon.
> 
> Well, anyway i cannot think of any 'clean' and 'elegant' solution for this
> problem. Just wondering whether one day Cocoon will has customized way to
> recognize user agent.
> 
> Does anybody has idea about this?

Cocoon2 provides/will-provide what you need: they are called "matchers"
and are pluggable classes that allow you to say

 boolean matches(HttpServletRequest request)

to a request that arrives on the specific URI (using the Sitemap). With
such toys, you can perform whatever analysis on your request, even the
most complicated one, then simply say "yeah, this is for me".

So you basically do mapping with "uri" + "matcher"... in fact, we
already know that "uri" mapping is not enough... but also you can do
very fancy matching like

 - BandwidthLoadMatcher ----> apply the low-bandwidth stylesheet when
your backbone is under heavy load... so that you create a negative
feedback that should stabilize your system: which means "if you have
band, use it, if you don't, try to save it".

 - TimeOfTheDayMatcher ---> apply a different stylesheet depending on
the time of the day... in the requestor's time zone! the dawn
stylesheet, the night stylesheet... and so on.

and so on... once you have the complete sitemap architecture in place,
mapping thru "user-agent" will be piece of cake and I'm sure you guys
will come up with so many new usages I cannot even dream of.

Pier, BTW, what's the status of the matching subsystem?
 
> Anyway, thank you to the creator, for this great product.

You're welcome  :)
 
-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------