Dear John,
I'm not sure one of these topics would be suitable for my thesis, so I think
for now I'll just stick with DERBY-728 and make my GSoC application based on
this, with Kathey as my mentor. Thank you for the list though.
Tiago
________________________________
From: Ян Программист <webautoma...@gmail.com>
To: derby-dev@db.apache.org; tiago.de...@yahoo.co.uk
Sent: Sat, 13 March, 2010 9:15:20
Subject: Re: Google Summer of Code
Very interesting. And I am also having some interesting ideas for
participating in Google soc. Here some of them:
JavaDB enchantments
Main disadvantages of official JavaDB build
* JDBC only connector
* JDBC is catastrophically slow
* SQL reusing does not solve architecture problems
* Embed configuration is not always possible/sometimes is not
always desirable
* There is no storage engine porting available(JavaDB storage
engines are not compatible for non-Java databases)
* Importing/exporting of DDL of other database vendors. Bad
migration from Oracle/SQL Server/PostreSQL/MySQL/MSQL/HyperSQL
* Is not clearly understood how to inject additional JOIN/UNION
algorithms/strategies
* SQL result records could not be transformed afterwards but
before sent to client lib – all transformations are extra heavy for
client application
* Custom column types, serialization and indexing support for
those custom types – nothing serious at this moment
* No actual compatibility tests for Oracle, SQL Server
What would be great to be supported in JavaDB
* Java to bytecode & bytecode to native build with configuring
what parts to be built as native C/C++ and called via JNI and what
features to be configured on
* Sun Studio tests tools for JNI and JavaDB in particular:
* Java to C
* C to Java
* C to Java to C
* Java – C – Java
* Performance tips for JVM/Sun Studio/JNI over JVM
* OpenSolaris/Solaris configuration
* libumem with JNI
* SQL support transforming SELECT requests – data transformations
* WSDL publishing when deploying JavaDB
* XML formatter unlike binary. Less speed but more flexibility
* AXIS for publishing Java objects as Web services
* Implementing other gateways:
* Servlet
* Applet
* HTTP Server
* As a variantRESTful: less URL length -& better carrying capacity
* Stress testing for qualified stability and failure-resistance
* Table columns extensibility
* Floating row count extensibility
* Importing JavaDB configuration from XML on-the-fly
* RPC support based on JavaDB core
* Ability to build JavaDB with embed RPC support
* JDBC support could be switched on/off(thus RPC could be primary
tactic for client connectivity)
* VIEWS generation support from XML, SQL + XML
* Same as in (11) but usinghttp://xmlrpc-c.sourceforge.net/from
the client side
* libumem +http://xmlrpc-c.sourceforge.net/threw Sun Studio compiler support
* HTTP routes for HTTP server gateway:
* Route redirections for separate JavaDB/Derby servers
* Hot plug of redirection configurations instead of long & heavy
files like .htaccess
* Caching support for HTTP routes
* Mirroring from the side of HSQLDB http gateway implementation
(JavaDB + HSQLDB replication)
* JavaDB with MQ support performance:
* JavaDB using non-embed configuration with separated ActiveMQ broker
* Swapping between different message brokers at runtime
* JavaDB embed into JMS broker
* Implementing an SQL storage engine, in witch a BLACKHOLE-like
table where inserted rows via SQL will be automatically grabbed with
message broker and sent to specific endpoint
* RabbitMQ broker
* ActiveMQ as Java solution vs RabbitMQ as R-lang based solution
* WebDAV with JavaDB as storage with embed/non-embed configuration
on Sun Java System Web Server
* Good idea is to use memcacheq – when there is cached messages
and cached redirects
* Using Java Fork/Join Framework for JavaDB/JMS queues
* Implementation of joining two or more message streams at runtime
* While joining several streams to one joining of messages should
be prioritized
* Implementation of on-the-fly swap of two messages from parallel
message streams (but with same priority on both for compatibility with
priorities features)
* Priority-driven SQLs
* Swap/join SQL result(data) capabilities
* Client-side plug-in for automated in-place injection (useful
mostly for Web applications)
* Format would support: JSON/YAML/XML/Bytecode format, AMF0, AMF3
Connect to a community discuss, Tiago! John
2010/3/12 Tiago Espinha <tiago.de...@yahoo.co.uk>:
> Dear all,
>
> My name is Tiago Espinha and I participated in last year's edition of Google
> Summer of Code. I've decided to participate again this year and after
> speaking with Kathey (my mentor from last year) she suggested that I'd take
> on her DERBY-728. This issue seems overly complex for a newcomer and I've
> had previous experience with contributing to Derby.
> With this said, I'm taking on this issue for now and apply for GSoC with
> this issue in mind. I know that when it comes to GSoC, Apache will have to
> submit a list of possible projects for students to apply for. Is it possible
> that this is one of the possible projects? Or will I have to apply under
> "derby-testandfix"?
> In conversation with Kathey, I also considered another possibility, but for
> this I'd like some input from the community. This year I'm doing a Master's
> degree in Advanced Software Engineering, and I thought that perhaps it would
> be possible to take a Derby project as my Master's thesis. My department
> allows me to submit my own idea, but what I would like to know is if there
> is any outstanding, cutting-edge feature that we could possibly integrate
> into Derby, even if just in an experimental basis.
> On my course, there are two main focuses: service oriented architectures
> (web services and all aspects related to web service modelling) and model
> driven development (MDD). I'm not sure how familiar you are with the concept
> of MDD, as it does not seem to be something with a lot of hype surrounding
> it, but I think it could possibly be a good concept to apply to Derby. I've
> just been introduced this year to this concept and basically it boils down
> to generating code from models. So instead of writing Java code, we simply
> create a model and generate code from that; apparently this is being used in
> some companies and most of the times up to 90% of the code can be generated
> automatically. The remaining 10% are written by hand afterwards.
> This is just food for thought, if you know of any other issues/features that
> would make a good thesis subject, I'm open to suggestion.
> For now, however, I'll be taking on DERBY-728.
> Regards,
> Tiago Espinha
>
