138 lines
6.9 KiB
Plaintext
138 lines
6.9 KiB
Plaintext
head 1.5;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
expand @o@;
|
|
|
|
|
|
1.5
|
|
date 2008.05.25.22.44.33; author JamesYtow; state Exp;
|
|
branches;
|
|
next 1.4;
|
|
|
|
1.4
|
|
date 2008.04.20.22.15.28; author DonaldHobern; state Exp;
|
|
branches;
|
|
next 1.3;
|
|
|
|
1.3
|
|
date 2008.04.18.08.20.33; author PatriciaMergen; state Exp;
|
|
branches;
|
|
next 1.2;
|
|
|
|
1.2
|
|
date 2008.04.18.00.40.33; author PiersHiggs; state Exp;
|
|
branches;
|
|
next 1.1;
|
|
|
|
1.1
|
|
date 2008.04.17.23.31.34; author DonaldHobern; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@none
|
|
@
|
|
|
|
|
|
1.5
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@%META:TOPICINFO{author="JamesYtow" date="1211755473" format="1.1" version="1.5"}%
|
|
%META:TOPICPARENT{name="TapirSoftware"}%
|
|
---++ Implementing a TAPIR provider in Java
|
|
|
|
There are many projects which use Java as their development language and which would benefit from a Java implementation of the provider software for use as a pluggable module inside other applications or directly as a web application. This page is for those who have an interest in such a development to discuss requirements and to consider possible solutions.
|
|
|
|
An initial question to be addressed is whether a Java implementation should simply seek to replicate the functionality of the existing implementations in other languages, or make additional enhancements, for example to support other back-end data sources in addition to relational databases.
|
|
|
|
I would like to encourage those who have an interest in a Java provider implementation to add their thoughts here. In particular, please try to address:
|
|
|
|
* *Requirements* - describe your motivation for an interest in this area, particularly any project drivers and time lines, and any special functional needs
|
|
* *Capacity* - do you have any available capacity for contributing to an open source development activity, as a designer, developer, tester, etc.?
|
|
* *Progress* - if you have already started work on an implementation, how advanced are you?
|
|
|
|
If you are also working on related components, e.g. a Java client library for TAPIR, please give some details on these too.
|
|
|
|
Many thanks,
|
|
|
|
Donald
|
|
|
|
---++Responses
|
|
|
|
*Piers Higgs, Gaia Resources, Perth, Western Australia*
|
|
|
|
* *Requirements* - we have built a complex web app in Java and while we've played around with TAPIRLink and got it working but a Java version would be "nice". We are also working on a range of projects relating to data servers for organisations in Australia and it would be "nice" to have a Java option. These are our two main projects and drivers. Timelines are a bit flexible for us as we can get the required functionality with the existing TAPIRLink.
|
|
* *Capacity* - we have a senior Java developer in house, currently recruiting for an additional Java developer (who isn't?). Our project work on data servers gives us the possibility of also providing test beds for this work. As a private consulting organisation, we'd probably keep our involvement to a small amount as we focus on chargeable work more (unless funding was available).
|
|
* *Progress* - None.
|
|
|
|
*Patricia Mergen, Royal Museum for Central Africa, Tervuren, Belgium*
|
|
|
|
* *Requirements* - Would it not make sense that we devote our ressources on enhancing the current Tapir implementations rather than replicate a new one entirely in Java? I agree that from a purist IT point of view this would make sense and to have something "nice", that Java offers a lot of libraries and has a very large user community. However as far as I am aware of it there are now Tapir tools and modules in Python, php, Java ... . All these languages are platform independent and modules for a same service written in different languages are or can be made interoperable. So maybe the approach could be to test the currently availablre Tapir tools, assess the + and - and than see what additional modules may be needed, which can of course be developed in Java, rather than a complete new implementation of Tapir in Java. Or are their other constrains and needs that I am not aware of?
|
|
|
|
_Thanks, Patricia. This is certainly an important question. Clearly the case for multi-language client libraries is much clearer than for server libraries. However I do think that it would be exciting to develop a Java processor capable of parsing and handling TAPIR requests and then using a pluggable framework for data sources, which could potentially include sources other than relational databases (e.g. in-memory data or links to business logic implemented in Java). Given the range of Java-based applications being developed, it does seem likely that being able to embed a Java provider implementation directly in a Java deliverable (JAR or WAR) could be a great simplification over having requiring coupling with a PHP, Python or C# implementation. In any case, it is really important to get everyone else's view on this point, before we proceed further. - DonaldHobern, 21 April 2008_
|
|
|
|
Main.JamesYtow - 25 May 2008
|
|
* *Requirements* - I'd like to use TAPIR to access data sources from our Java application program comparing multiple hierarchies. I hope that we can extract some 'concepts' even from DarwinCore or ABCD data. Is there any TCS-ish provider using TAPIR? We have access to uBio already.
|
|
* *Capacity* - A lazy, parttime programmer (me!) is available.
|
|
* *Progress* - Just porting TapirChirp to Java. Half done as number of classes without any test. They are packaged in org.tdwg.tapir, but I'm open to other naming convention, e.g. org.tdwg.tapir.client to keep place for provider codes (by others).
|
|
|
|
-- Main.DonaldHobern - 17 Apr 2008@
|
|
|
|
|
|
1.4
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="DonaldHobern" date="1208729728" format="1.1" version="1.4"}%
|
|
d35 4
|
|
@
|
|
|
|
|
|
1.3
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="PatriciaMergen" date="1208506833" format="1.1" version="1.3"}%
|
|
d31 3
|
|
a33 1
|
|
* *Requirements* - Would it not make sense that we devote our ressources on enhancing the current Tapir implemtations rather than replicate a new one entirely in Java? I agree that from a purist IT point of view this would make sense and to have something "nice", that Java offers a lot of libraries and has a very large user community. However as far as I am aware of it there are now Tapir tools and modules in Python, php, Java ... . All these languages are platform independent and modules for a same service written in different languages are or can be made interoperable. So maybe the approach could be to test the currently availablre Tapir tools, assess the + and - and than see what additional modules may be needed, which can of course be developped in Java, rather than a complete new implementation of Tapir in Java. Or are their other constrains and needs that I am not aware of?
|
|
@
|
|
|
|
|
|
1.2
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="PiersHiggs" date="1208479233" format="1.1" reprev="1.2" version="1.2"}%
|
|
d29 6
|
|
a34 1
|
|
-- Main.DonaldHobern - 17 Apr 2008
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="DonaldHobern" date="1208475094" format="1.1" version="1.1"}%
|
|
d21 9
|
|
a29 1
|
|
-- Main.DonaldHobern - 17 Apr 2008@
|