db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ян Программист <webautoma...@gmail.com>
Subject Re: Google Summer of Code
Date Sat, 13 Mar 2010 09:15:20 GMT
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.derby@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
>

Mime
View raw message