Hi Jakub,

On 31.03.2011 23:17, Jakub Narloch wrote:
> Hello,
> 
> My name is Jakub Narloch, I am student at Warsaw University of
> Technology in Poland. Currently I am at first year of Master studies (I
> had already graduated 3.5 year studies with engineer title, so
> altogether, this is my 5 year of studying). I would like to participate
> in one of the Castors XML projects. But to do so I would like to ask for
> some additional information.
Sure. Just read on ....
> 
> As for my previous experience, I had already gained some by working as
> Java developer for private company in Poland. Besides that I took part
> in contests hosted by TopCoder Inc for some time, also I am  currently
> member of TopCoder’s Component Development Review Board.
> 
> Below are the questions I would like to ask You:
> 
> Idea 1: Spring-OXM extensions:
> 
> I had been working with Spring-WS in past, so I am quite familiar with
> this framework. Currently the implementation looks very straightforward,
> it wraps the Castor XMLContext and Marshaller and Unmarshaller into
> single class org.springframework.oxm.castor.CastorMarshaller. The class
> does all the work for configuring the Castor, by settings mapping files
> etc. I would like to ask with what additional functionality exactly You
> would like to extend the Spring OXM?
There's a few things on the XMLContext/Unmarshaller/Marshaller side of
things that are currently not exposed through OXM's CastorMarshaller. SO
the project would be split between an analysis phase (what's actually
missing?) and an actual implementation.
> 
> Idea 2: StAX for marshalling:
> 
> This seems quite self explanatory. The idea is to allow marshalling with
> help of StAX. However the number of classes that directly depends of SAX
> API is quite large, below are mentioned only the packages that I believe
> are directly used during object marshalling:
> 
>    * · org.exolab.castor.xml
>    * · org.exolab.castor.xml.util
> 
> I most concerned on the scope. I assume that only classes from those
> packages will have to be refactored, am I right here? Or maybe You wish
> to add such additional StAX support to whole component, in some generic
> way, e.g. for loading the mapping files?
Correct, the idea here is simple, the implementation might be a bit more
complex. As you noticed already, currently OO--> XML transformation is
supported through SAX events (streaming) only. In order to support StAX
as well, quite some refactoring will be required.

I am actually not sure what classes will be affected, but at minimum a
little 'layer' will be required that is capable of using any of the
underlying XML technologies. Does this make sense ?


> I have additional question, this time more about the formal
> requirements. My question is connected with this statement (from Castor
> idea page):
> 
>    * Have a look at the Castor sources (via SVN), identify code
>      relevant to the proposal you are interested it and show us your
>      ideas by the means of a patch.
> 
> As I understand I may try to implement my idea (at least in some limited
> way) and sent You as a patch. How much complex it has to be then? 
Well, you do not have to send a patch that actually provides an
implementation, as that's the actual work you are meant to be doing
during GSoC. But such a patch could f.e. have - at the very minimum -
comments in side that identify the code fragments where things will need
to change. Or if you went about the idea mentioned above (adding a
layer), such patch could include pseudo code wrt this layer, etc.

> Also
> until when may I send it, is there some kind of deadline besides the
> GSOC acceptance date? 
No, but we expect this to be part of the proposal, so that we can make
well informed decisions about your proposals. Now, if you gave us a
patch on the very last day, it would be a pity.

Why not look at this as an incremental process by which we try to assess
your skills (Java, coding, software engineering) and your enthusiasm.

> Do You treat this as obligatory?
Yes, pretty please. It's not so much about a perfect proposal/patch, but
more about you engaging with us/the project, and show us that you
actually mean it.

> I had already started working on the proposals. Any additional
> information would be helpful for me.
Well, we are available in various ways: email, irc, ....

Kind Regards
Werner
> 
> Thank You in advance.
> 
> Regards,
> Jakub Narloch
> jmnarl...@gmail.com
> 
> 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to