beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie ONeil <ekon...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Fri, 08 Jul 2005 12:59:58 GMT
  +1

  That's the argument that's been made for a while -- now, let's just build it.

  :)



On 7/8/05, Davanum Srinivas <davanum@gmail.com> wrote:
> I agree with Rich. PLEASE use an XML Schema for our model.
> 
> -- dims
> 
> On 7/8/05, Rich Feit <richfeit@gmail.com> wrote:
> > Thanks for the info in this and the previous response.  For my part (and
> > at this point I'm really just an observer of the WSM codebase), I would
> > still go with an XML schema that matches the model you build.  WSDL is
> > standard, but it seems like it's a standard for expressing a public
> > interface, not a standard for this particular use.
> >
> > Rich
> >
> > Daryoush Mehrtash wrote:
> >
> > >On 7/7/05, Eddie ONeil <ekoneil@gmail.com> wrote:
> > >
> > >
> > >>  Agreed.  A WSM-specific XML file seems like the right way to go here.
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >>  Producing a partial WSDL will be weird for the user as it's just
> > >>used as a transport for our own information but we use a name (wsdl)
> > >>that implies more than that.
> > >>
> > >>
> > >>
> > >
> > >
> > >The only thing "partial" about the WSDL that we can generate at APT
> > >time is that its  schema types would not be fully defined.  Or at
> > >least I don't see how one can determine the  schema types unless you
> > >actaully load and run the classes.   Other than schema type the WSDL
> > >would be complete.
> > >
> > >
> > >
> > >
> > >
> > >>Eddie
> > >>
> > >>
> > >>
> > >>
> > >
> > >daryoush
> > >
> > >
> > >>On 7/7/05, Davanum Srinivas <davanum@gmail.com> wrote:
> > >>
> > >>
> > >>>-0 to wsdl. +1 to (XML schema that conforms more to the model)
> > >>>
> > >>>-- dims
> > >>>
> > >>>On 7/7/05, Rich Feit <richfeit@gmail.com> wrote:
> > >>>
> > >>>
> > >>>>A few questions about this (again, I'm just trying to educate myself
here):
> > >>>>
> > >>>>    - If WSDL is the "overwrite" format, then this means deployment-time
> > >>>>overwriting would have to be done through WSDL, right?
> > >>>>    - Let's say that *all* the extra information you need is parameter
> > >>>>names.  Can valid WSDL be sparse enough to make sense for this?
> > >>>>    - Why wouldn't it be possible to generate type information during
> > >>>>apt processing?  apt/Mirror gives you a superset of what you have
at
> > >>>>runtime.  Or is it just logically impossible to get the right
> > >>>>information during the processing stage?
> > >>>>    - At a root level, why is WSDL a better format than an XML schema
> > >>>>that conforms more to the model?
> > >>>>
> > >>>>Thanks,
> > >>>>Rich
> > >>>>
> > >>>>Daryoush Mehrtash wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>>An idea from "sleepless night in Seattle" :)
> > >>>>>
> > >>>>>I think there is an overall agreement that we need *something*
to keep the
> > >>>>>missing information form class files. And we all seem to agree
that the
> > >>>>>serialized java file is not the right solution.
> > >>>>>
> > >>>>>Instead of creating yet another XML file, why not just use a
WSDL file to be
> > >>>>>the additional information. We can build a WSDL (minus its type
information)
> > >>>>>during the APT process. In run time the code would look something
like:
> > >>>>>
> > >>>>>Load the object model from reflection (java.reflection or ASM)
> > >>>>>
> > >>>>>If there is a WSDL file
> > >>>>>
> > >>>>>To the extend possible use the WSDL information to over write
the JWS
> > >>>>>settings
> > >>>>>
> > >>>>>Make sure there are no conflicts between WSDL and JWS file
> > >>>>>
> > >>>>>Run the web serviceā€¦.
> > >>>>>
> > >>>>>I don't believe it would be possible to generate the WSDL's
type information
> > >>>>>during the APT processing. Furthermore, the real WSDL of the
service is
> > >>>>>generate by the SOAP stack, and may be different from the WSDL
file that is
> > >>>>>generated during the APT processing. Nevertheless I think the
WSDL (or a
> > >>>>>subset of a complete WSDL) would be a logical format to keep
the missing
> > >>>>>information.
> > >>>>>
> > >>>>>Thoughts?
> > >>>>>
> > >>>>>Daryoush
> > >>>>>
> > >>>>>
> > >>>>>On 7/6/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>Yes. We essentially need some information that is lost when
the JWS
> > >>>>>>files are compiled. The curent solution is to build the
complete
> > >>>>>>object model during the APT build process. The model containes
all
> > >>>>>>that is needed to run the web service (information on the
web
> > >>>>>>servicer, every method, parameter etc). Most of the information
is
> > >>>>>>available from the class file, so the serialized information
is
> > >>>>>>redundant, and as Eddie has said at time the information
is not even
> > >>>>>>valid.
> > >>>>>>
> > >>>>>>For run time I am proposing we build the model of the web
service from
> > >>>>>>the JWS class file, but have a file that would over write
the
> > >>>>>>information in the class files.
> > >>>>>>
> > >>>>>>At build time we can save the missing information to this
file. We
> > >>>>>>only need the parameter names, but the same mechanisem could
> > >>>>>>potentially be used by a deployer to overwrite the information
in the
> > >>>>>>class files.
> > >>>>>>
> > >>>>>>Right now we are dependent on APT process. But in my model
you can
> > >>>>>>also work based on straight Javac. Although with APT you
get a more
> > >>>>>>conformant (default parameter names) implementation.
> > >>>>>>
> > >>>>>>Daryoush
> > >>>>>>
> > >>>>>>On 7/6/05, Richard Feit <richard.feit@bea.com> wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>Just to make sure I'm clear on this, we're talking about
something that
> > >>>>>>>*was* a Serialized object written to a ".ser" file,
but that will no
> > >>>>>>>longer have anything to do with Serialization? The "overwrites"
that
> > >>>>>>>you're talking about are simply the parameter names,
written to XML?
> > >>>>>>>
> > >>>>>>>Just trying to understand -- I haven't been involved
in the coding of
> > >>>>>>>this piece, so I'm starting from scratch here.
> > >>>>>>>
> > >>>>>>>Thanks,
> > >>>>>>>Rich
> > >>>>>>>
> > >>>>>>>Daryoush Mehrtash wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>>Beside the format of the ".ser" file we also need
to reach closure on
> > >>>>>>>>its content and its role.
> > >>>>>>>>
> > >>>>>>>>Right now the .ser file contains the complete model
and is the sole
> > >>>>>>>>means to build the object model at run time. I think
we need to change
> > >>>>>>>>both aspect of the .ser file.
> > >>>>>>>>
> > >>>>>>>>My suggestion on this is to always build the run
time object model of
> > >>>>>>>>the web service based on Reflection (or similar
class analysis e.g.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>ASM)
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>and use the ".ser" (in any format you choose to
keep it) to overwrite
> > >>>>>>>>the reflection information. The ".ser" then doesn't
have to be a
> > >>>>>>>>complete model, rather it would only contain the
overwrites. The
> > >>>>>>>>overwrites would take precedence over the class
file annotations and
> > >>>>>>>>would be used by the build process, or deployment
process to control
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>the
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>final web service.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>Daryoush
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>-----Original Message-----
> > >>>>>>>>>From: Eddie ONeil [mailto:ekoneil@gmail.com]
> > >>>>>>>>>Sent: Wednesday, July 06, 2005 10:13 AM
> > >>>>>>>>>To: Beehive Developers; mmerz@acm.org
> > >>>>>>>>>Cc: Eddie O'Neil; Daryoush Mehrtash
> > >>>>>>>>>Subject: Re: Role of .ser file in WSM
> > >>>>>>>>>
> > >>>>>>>>>And, again, I can see the value of having *something*
that conveys
> > >>>>>>>>>this information (the formal argument names),
but I disagree with
> > >>>>>>>>>using a serialized Java object to convey this
information -- the .ser
> > >>>>>>>>>file.
> > >>>>>>>>>
> > >>>>>>>>>Seems to me that there are more architecturally
flexible / loosely
> > >>>>>>>>>coupled ways of conveying this information than
serializing the entire
> > >>>>>>>>>object model (which includes fully-qualified
paths from the build
> > >>>>>>>>>environment). Information like these fully qualified
paths shouldn't
> > >>>>>>>>>be made available to the runtime side.
> > >>>>>>>>>
> > >>>>>>>>>That's why I was suggesting either XML or a
generated BeanInfo file.
> > >>>>>>>>>
> > >>>>>>>>>Hope that's clear...
> > >>>>>>>>>
> > >>>>>>>>>Eddie
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>On 7/6/05, Michael Merz <michael.merz@gmail.com>
wrote:
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>Hi guys,
> > >>>>>>>>>>
> > >>>>>>>>>>Sorry for the late response -- I've been
*really* busy for a while
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>;)
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>There were reasons for using a .ser file,
the most prominent one
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>being
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>that interfaces will *not* contain the parameter
names of methods --
> > >>>>>>>>>>even when compliled with the debug version.
A serialized object
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>model
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>file seemed to be the only way of capturing
all information.
> > >>>>>>>>>>
> > >>>>>>>>>>I agree that the .ser-file/object model
needs some clean-up since it
> > >>>>>>>>>>has "grown". If you'd like to work on it,
I would suggest storing
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>all
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>metadata (as it will be used, i.e. with
defaults where applicable)
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>in
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>a .ser file rather than just select/currently
required information
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>and
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>to stay closer to the way that information
is organized in 181.
> > >>>>>>>>>>
> > >>>>>>>>>>Cheers,
> > >>>>>>>>>>
> > >>>>>>>>>>-michael
> > >>>>>>>>>>
> > >>>>>>>>>>--
> > >>>>>>>>>>Michael Merz
> > >>>>>>>>>>mmerz@acm.org
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>Yeah -- if at all possible, it seems good
to avoid generating code
> > >>>>>>>>>>in the WSM case just because we don't need
to, though it's a good
> > >>>>>>>>>>point -- I'd forgotten controls did that.
> > >>>>>>>>>>
> > >>>>>>>>>>But, it could definitely work either way.
A source code file
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>seems
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>easier to deal with than a serialized object
for the obvious
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>reasons.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>It's just that the XML file seems sufficient
for today's needs...
> > >>>>>>>>>>
> > >>>>>>>>>>Eddie
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>On 6/8/05, Daryoush Mehrtash <dmehrtas@bea.com>
wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>>In WSM we don't generate any source
code, so far ".ser" has been
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>our
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>only artifact that we generated.
> > >>>>>>>>>>>=20
> > >>>>>>>>>>>If we want to go the route of generating
any file, a XML file
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>might be
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>a
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>>better option.
> > >>>>>>>>>>>=20
> > >>>>>>>>>>>daryoush
> > >>>>>>>>>>>=20
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>>-----Original Message-----
> > >>>>>>>>>>>>From: Kyle Marvin [mailto:kylemarvin@gmail.com]
> > >>>>>>>>>>>>Sent: Wednesday, June 08, 2005 2:34
PM
> > >>>>>>>>>>>>To: Beehive Developers
> > >>>>>>>>>>>>Subject: Re: Role of .ser file in
WSM
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>On 6/8/05, Daryoush Mehrtash <dmehrtas@bea.com>
wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>.ser file exist for one reason
and one reason only. JSR 181
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>says
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>that
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>>>name of a @WebParam by default
is:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>Name of the parameter as it
appears in the argument list.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>The issue is that this name
gets lost after the class is
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>compiled.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>The
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>>>original WSM was based on Reflection
that there was no
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>Serialized
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>file.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>>>An alternative solution is to
require the JWS files to be
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>compiled
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>with
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>>>Debug option which preserves
the argument names.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>Is it needed? Well it depends
on your preferred method to get
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>the
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>>>argument name: require the user
to compile its JWS in debug,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>or
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>keep
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>>>the serialized file. Is there
a third option?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>The Controls runtime stores method
parameter names into
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>generated
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>code
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>>>associated with the original interface.
These names are used
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>to
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>>support named argument lookup during
extensible method
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>invocation.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>=20
> > >>>>>>>>>>>=20
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>--
> > >>>>>>Daryoush
> > >>>>>>
> > >>>>>>Weblog: http://perlustration.blogspot.com/
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>--
> > >>>Davanum Srinivas -http://blogs.cocoondev.org/dims/
> > >>>
> > >>>
> > >>>
> > >
> > >
> > >
> > >
> >
> 
> 
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>
Mime
View raw message