Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: domain of webautomator@gmail.com
 designates 209.85.220.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=FhTPfspocLbRgW1MQYTrubc+4IcOZzDuJP8SzFQz6FVC3qE/WAj96JKhdRn0eW618+
         +15ch/39sdbRUrijcMbUWdS9AsOEpxKzTbzBgAbd8JsYCysVFkdwrbLMtxwalWTk1Z9r
         3334t08h0SwIJ9vQHysX3PMfESDyHgECmv++w=
MIME-Version: 1.0
In-Reply-To: <855911.22501.qm@web29112.mail.ird.yahoo.com>
References: <855911.22501.qm@web29112.mail.ird.yahoo.com>
Date: Sat, 13 Mar 2010 11:15:20 +0200
Message-ID: <93d36c111003130115q34926e6j8a4f3aec9651a486@mail.gmail.com>
Subject: Re: Google Summer of Code
From: =?KOI8-R?B?8c4g8NLPx9LBzc3J09Q=?= <webautomator@gmail.com>
To: derby-dev@db.apache.org, tiago.derby@yahoo.co.uk
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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 =96 all transformations are extra heavy for
client application
    * Custom column types, serialization and indexing support for
those custom types =96 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 =96 C =96 Java
    * Performance tips for JVM/Sun Studio/JNI over JVM

    * OpenSolaris/Solaris configuration
    * libumem with JNI
    * SQL support transforming SELECT requests =96 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 su=
pport
    * 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 =96 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 Goo=
gle
> 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 ta=
ke
> 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 t=
o
> submit a list of possible projects for students to apply for. Is it possi=
ble
> 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 f=
or
> 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 wo=
uld
> 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 ther=
e
> 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 conc=
ept
> of MDD, as it does not seem to be something with a lot of hype surroundin=
g
> 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 dow=
n
> to generating code from models. So instead of writing Java code, we simpl=
y
> 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 generat=
ed
> automatically. The remaining 10% are written by hand afterwards.
> This is just food for thought, if you know of any other issues/features t=
hat
> would make a good thesis subject, I'm open to suggestion.
> For now, however, I'll be taking on DERBY-728.
> Regards,
> Tiago Espinha
>