Public Review of SKSML v1.0

FYI.
The OASIS EKMI Technical Committee would be grateful for any comments
received from members of this forum about the key-management protocol.
If you are interested in reviewing a working implementation of an early
version of this protocol - written completely in Java - , you can get the
implementation here:
http://www.strongkey.org.
Thank you.
Arshad Noor
StrongAuth, Inc.
----- Forwarded Message -----
From: "Mary McRae" <[email protected]>
To: [email protected], [email protected]
Cc: "ekmi" <[email protected]>
Sent: Thursday, July 24, 2008 7:04:49 PM (GMT-0800) America/Los_Angeles
Subject: [ekmi] Public Review of SKSML v1.0
To OASIS members, Public Announce Lists:
The OASIS Enterprise Key Management Infrastructure (EKMI) TC has recently
approved the following specification as a Committee Draft and approved the
package for public review:
Symmetric Key Services Markup Language (SKSML) Version 1.0
The public review starts today, 24 July 2008, and ends 23 September 2008. This
is an open invitation to comment. We strongly encourage feedback from potential
users, developers and others, whether OASIS members or not, for the sake of
improving the interoperability and quality of OASIS work. Please feel free to
distribute this announcement within your organization and to other appropriate
mail lists.
More non-normative information about the specification and the technical
committee may be found at the public home page of the TC at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi. Comments may be
submitted to the TC by any person through the use of the OASIS TC Comment
Facility which can be located via the button marked "Send A Comment" at the top
of that page, or directly at:
http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ekmi.
Submitted comments (for this work as well as other works of that TC) are
publicly archived and can be viewed at:
http://lists.oasis-open.org/archives/ekmi-comment/. All comments submitted to
OASIS are subject to the OASIS Feedback License, which ensures that the feedback
you provide carries the same obligations at least as the obligations of the TC
members.
The specification document and related files are available here:
Editable Source (Authoritative):
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.odt
PDF:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.pdf
HTML:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.html
Schema:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/schema/
Abstract:
This normative specification defines the first (1.0) version of the Symmetric
Key Services Markup Language (SKSML), an XML-based messaging protocol, by which
applications executing on computing devices may request and receive symmetric
key-management services from centralized key-management servers, securely, over
networks. Applications using SKSML are expected to either implement the SKSML
protocol, or use a software library - called the Symmetric Key Client Library
(SKCL) - that implements this protocol. SKSML messages are transported within a
SOAP layer, protected by a Web Services Security (WSS) header and can be used
over standard HTTP securely.
OASIS and the EKMI TC welcome your comments.
Mary P McRae
Manager of TC Administration, OASIS
email: [email protected]
web: www.oasis-open.org

ejp wrote:
And who is constructing another list of rules?
You* are.No,I am not costructing any more rules but asking if I missed any rules,since I am unsure of all the rules.May be in some other page of JLS ,some more rules may be defined.
My question is simple,I have these set of rules extracted from JLSExactly. Here is where you are 'constructing another list of rules'.No,again.
extracted from JLS and I just wanted to review them.Why? You have the JLS. You also have the compiler.Very True,I am reviewing them.
Perhaps,I was not clear enough. :)No, you were clear enough, you just didn't have any motivation for what you are doing.The motivation was just to make sure that I knew the rules for declaring a top class level class.And yes,I will read JLS to find out some more than these(if they exist).

Similar Messages

Java Card 2.2.2 draft is out for public review

A draft for the upcoming release of the Java Card Specification is available for public review.
The Java Card 2.2.2 Specification will provide numerous enhancements to the award-winning Java Card platform. In particular it will include specific support for contactless communication and ID cards :
* enhancements to ease the management and increase interoperability of contactless cards.
* additional cryptography and security features
* utility APIs for memory-efficient applet development
Java Card technology v2.2.2 is ready for the next generations of smart card standards, and is fully backward-compatible with previous versions.
New features in Java Card 2.2.2 :
* Utility APIs for TLV, BCD, short, int
* ISO7816-based Extended length APDU support
* Support for up to 20 logical channels
* External memory access API
* Multiple Interfaces management
* Additional cryptography algorithms : HMAC-MD5, HMAC-SHA1, SHA-256 and Korean Seed
* Signature with message recovery
* Partial message digest
* Standardized Biometrics API
Please direct your comments on this draft at [email protected] Feedback received before December 15th will be considered for the final version of the specification. For more information on the Java Card Platform Specification v2.2.2, Public Review Draft, refer to the release notes on http://java.sun.com/products/javacard/RELEASENOTES_jcspecsp.html

The Installer and the Applet Deletion Manager are implemented in the JCRE and GlobalPlatform. On-card the Card Manager manages the content management, communication and the related security. JCRE specifies how it has to handle installation and deletion, but leaves room for different implementations. To the outside world, on a GP card, the Installer/ADM is the Card Manager with a specific AID.
Installer and ADM are optional. For instance a Java Card Static product does not need an Installer/ADM.
JCOP cards have the Installer/ADM fully implemented. It uses the GP functionality. The CM has to be selected to install or delete a package/applet.

JDBC 4.0 Public Review

The JDBC 4.0 Public Review Draft specification is now available on the JCP web site.
http://jcp.org/aboutJava/communityprocess/pr/jsr221/index.html
This is the JDBC spec that will be included in Java 6.0 so this is what you'll be living with for the next few years. I strongly encourage you to take a look at it.
There isn't much room to make significant additions or sweeping changes. Java 6.0 goes final fairly soon. What is important is to have as many eyes as possible review the spec and look for things that are unclear or broken.
Of course you can post comments here, in fact I encourge you to do so to refine your criticism, but the Expert Group will only see comments emailed to the address on the web page above.
Major new things include support for XML type, support for an unwrap method, factory methods for large objects, and a lot of bug fixes, clean up, and clarifications of the 3.0 spec. The XML support is intentionally minimal as this is a complex area. It is easier to add new methods than remove old broken ones. The unwrap method is somewhat subtle so look at it closely.
We didn't get any responses to the Early Review Draft. We would really like a lot more eyes looking for problems and helping to identify areas that are unclear. This is your opportunity to have an impact on the JDBC spec.

Well, the JDBC 4.0 specification is not yet final, as an implementor we cannot comment or fix a potential bug until the spec is final. Having said that I'll forward this to our rep at the JDBC JSR Expert Group.
Kuassi - http://db360.blogspot.com/

[Announce] WSRP 1.0 Primer available for public review

A public draft of WSRP 1.0 Primer is now available for review and
comments. This document may help those trying to figure out the nuts and
bolts of WSRP. If you have any comments, please post at the link below.
Subbu
A public review period for the WSRP v1 Primer (located at
http://www.oasis-open.org/committees/download.php/9002/wsrp-primer-1.0-draft-0.9.pdf)
will run until October 2, 2004. Please use the WSRP comment facility at
http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=wsrp to
provide feedback to the TC.
Rich Thompson
OASIS WSRP TC Chair

As explained by Marc Fluery of JBoss, there are essentially three types of
open-source:
1) Corporations that open their source for market share, such as IBM's Eclipse, that
then uses it to market WebSphere Studio
2) Hobbyist who develop an open-source project for free. The hobbyist may be a true
professional developer, but he is dedicated to his project as a hobby. In this situation,
donations are substantial enough to pay a dedicated developer.
3) Professional Open-Source in which developer is paid to maintain and develop an
open-source project in the hopes of making money with it through consulting and
professional services.
My question to the MyFaces team, which type of open-source are you?
As a corporate developer, I would hope it is Professional Open-Source, since that
model may have more support for the product I am using.
-Me

[ANNOUNCE] JSP 2.1 and Faces 1.2 Public Review

We are pleased to announce the availability of the Public Review
of the next versions of the specification for JavaServer Pages (JSP)
and JavaServer Faces (Faces). JSP 2.1 is developed under JSR-245 and
Faces 1.2 is developed under JSR-252. The two expert groups are working
ogether to improve the alignment between these two powerful web presentation
technologies.
Building on the work that was accomplished with the Early Draft
Review, this Public Review covers two additional areas that required
better integration between JSP and Faces:
- Tree Creation and Content Interweaving
- Deferred expressions nested within iteration tags
Please see Appendix E of the JSP spec and the
Preface of the Faces spec to see details of what's changed.
To access the specifications:
JSP 2.1 PR (JSR-245)
http://jcp.org/aboutJava/communityprocess/pr/jsr245/
Faces 1.2 PR (JSR-252)
http://jcp.org/aboutJava/communityprocess/pr/jsr252/
Sincerely,
The JSR-245 and JSR-252 Expert Groups

Can you confirm reports that the Unified EL is still not going to allow method calls on Java objects?
This has had a major impact on Joda-Time http://joda-time.sourceforge.net (a replacement for all the date and calendar classes in the JDK). The JSP and JSF specs expect to get all of their date objects as java.util.Date. However, our classes do not extend Date, but instead provide a toDate() method for easy conversion. However, with the EL being so restrictive it cannot call the toDate() method, causing no end of trouble.
The mailing list thread is here:
http://sourceforge.net/mailarchive/forum.php?thread_id=7037421&forum_id=8530
It really is incredibly narrow minded to block method calls from the EL. Joda-Time is just one of many projects that would benefit from allowing method calls. As it is, I will probably have to pollute the Joda-Time library by providing a getAsDate() method, which is frankly crap.

Jsr-201 including varargs in public review

Now that jsr-201 has gone into public review I have sent an email about varargs to:
[email protected]
I have included below some of the reasons why I think the Concise Object Array Literals syntax is better than their currently proposed varargs syntax.
They claim that most of the feedback they have got prefers the vararg syntax, I did another search in this forum and it still appears to me that people prefer the Concise Object Array Literals syntax , hence maybe others could also send their comments to [email protected]
* the callee can clearly see that they are passing in varargs
* the callee can pass in many var arg parameters, not just 1 at the end
e.g.
public void foo(int arg1, Object[] arg2, Integer[]) {
public void test() {
foo(1, {"hello", true, 5, 5L, 5F, 5.0}, {1, 2, 3});
}* the callee can choose to pass in a different number of arguments based on a condition:
e.g.
public void foo(int arg1, Object[] arg2, int arg3) {
public void test() {
foo(1, condition ? {"hello", true, 5, 5L, 5F, 5.0} : {"hello", true, 5}, 3);
}* the callee can call other 3rd party methods that already exist without having to wait for them to change all their methods to the ... syntax (Concise Object Array Literals is more compatible with existing code)

They claim that most of the feedback they have got
prefers the vararg syntax, I did another search in
this forum and it still appears to me that people
prefer the Concise Object Array Literals syntax ,
hence maybe others could also send their comments to
[email protected]
I don't like varargs, too. Your observation about this forum may be quite simple to explain - people who really understand problems with varargs do not write to these forums. For lots of people, typing extra { and } with concise array literals will not be an issue. However, they consider this extra curly braces "an overhead" and submit feedback that they like varargs syntax more, just because it does not have curly braces. It seems that they do not fully realize consequences or just simply have not spent enough time to think about them. At the first glance, of course, varargs will look more attractive than concise array literals for method calls.
I also object that "varargs are good because they help to see that certain method is interested only in values of array". We have javadoc for this! One can also use Tiger's annotation facility for this. There is no need to invent new syntaxt just for annotation/documentation. I'm alarmed when I read "this is what I like the most about varargs". It means - varargs are no good.
However, it may not be possible to resurrect concise array literals in Tiger due to timing. My opining on this matter is expressed fully in my JSR-201 comment. Here's a copy:
lease, do not include varargs as they currently specified into Tiger.
There seem to be too much controversy between varagrs and concise
array liters at this point. It is evident that a better solution that
addresses needs for both sides is needed. It may not be enough time to
find such solution for Tiger, but inclusion of varargs into the
language as they currently specified may ruin better alternatives in
the future. For example, concise array literals (or similar proposals)
will look extremely ugly combined with varargs as per PRD.
I understand that varargs are needed to support important marketing
features in Tiger like printf. Yes, it is marketing (with questionable
need in education sector), because real projects will not use printf.
Real projects are using logging and MessageFormat. They are not very
convenient without concise array literals, but at least everybody is
already accustomed to them. People have already written a lot of
helper classes themselves for MessageFormat&Logging that do not need
any varargs and have higher performance than PRD varargs will. They
simply declare methods with varying number of parameters. They have as
may version of their methods as their really need in their project.
This practice is not going to stop with introduction of varargs. Just
look at EnumSet.of(...) series of methods! This kind of
[unquestionably ugly] design even got into Tiger which already
supposed to have varargs.
Varargs break language clarity and consistency in too many places
(overloaded method resolution is clearly getting out of hands). I
doubt that varargs benefits justify their shortcomings.
However, if customer demand for varargs-like facility is overwhelming,
then, at least, consider alternatives that are not based on arrays.
Array-based varargs (as in PRD) are especially devastating for future
language evolution. A special interface or class shall be defined to
pass varargs behind the scenes. For example, the following interface
may be defined in "java.lang":
public interface Indexed<T> extends Iterable<T> {
public int size();
public T get(int index);
// Btw, java.util.List<T> can be retrofitted to implement Indexed<T>
So, in "myMethod(T... arg)" the arg will actually have a type of
"Indexed<T>" instead of "T[]".
This solves a lot of issues! For example, it will become possible to
define varargs based on generic types (which is not possible with
array-based varargs).
Moreover, when compiler creates code to call varargs method it may
create an instance of a special class for chosen small number of
arguments. It is obvious, that a special implementation of Indexed for
one element will be always faster on modern HotSpot than a
single-element array (although naive iteration with "foreach" facility
will require extra Iterator object, but that can be fixed if needed by
recognizing Indexed object as a special case in "foreach" statement).
Performance will be on the side of array-based varargs when number of
arguments is large, but something tells me that people who really need
varargs and drive their inclusion into Java do not care about
performance that much and will be perfectly Ok with extra object that
implements Indexed interface and wraps underlying array for many
argument cases.
In conclusion I must stress that if the following is legal in the
Java language (regardless of underlying implementation):
void myMethod(MyClass... arg); // declaration
myMethod(1, 2, 3); // call site
Then the following must be also legal:
MyClass... arg = 1, 2, 3;

PKGBUILD Public review request for wxFreeChart

Hi Arch Linux community.I am a newbie on Arch Linux. Just installed it a few months ago & I like it's install once, lifetime updates without reinstalling philosophy! Please review my first PKGBUILD for wxFreeChart:
http://wxcode.sourceforge.net/components/freechart/
Here is the PKGBUILD
# Maintainer: Sum <keansum AT gmail DOT com>
pkgname=freechart
pkgver=1.6
pkgrel=1
pkgdesc="Free powerful charting library based on wxWidgets."
arch=('x86_64' 'i686')
url="http://wxcode.sourceforge.net/components/freechart/"
license=('custom:"wxWindows"')
depends=('wxgtk')
source=(http://downloads.sourceforge.net/project/wxcode/Components/wxFreeChart/$pkgname-$pkgver.tar.gz
'configure.patch'
'LICENSE')
md5sums=('0e39d22a76c43df9e566ca1e1b669594'
'38dd8576fcd0b2c2e726499b2042a42d'
'9063869c9f1586dc0bd7c3f8d5060f76')
prepare() {
export CPLUS_INCLUDE_PATH=/usr/include/wx-3.0/:/usr/lib/wx/include/gtk2-unicode-3.0/
export LIBS=-lwx_gtk2u_adv-3.0
cd "$srcdir/$pkgname"
patch --verbose configure $srcdir/configure.patch
build() {
cd "$srcdir/$pkgname"
./configure --prefix=/usr
make
package() {
cd "$srcdir/$pkgname"
make DESTDIR="$pkgdir/" install
install -D -m644 $srcdir/LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
Here is the LICENSE file.
wxWidgets is currently licenced under the "wxWindows Library Licence" pending
approval of the "wxWidgets Library Licence" which will be identical apart from
the name.
The wxWindows Library Licence is essentially the L-GPL (Library General Public
Licence), with an exception stating that derived works in binary form may be
distributed on the user's own terms. This is a solution that satisfies those
who wish to produce GPL'ed software using wxWidgets, and also those producing
proprietary software.
Participants in the discussion that led to this decision include the folk from
AbiSource, Robert Roebling, Julian Smart, Markus Fleck, Karsten Ballueder, and
some advice from Richard Stallman. Richard has confirmed that the new licence
is compatible with GPL'ed applications. However, there are no significant
restrictions on proprietary applications.
The wxWindows Library Licence has been approved by the Open Source Initiative.
In August 2005, an ambiguity in Clause 2 was removed (replaced "the user's"
with "your") and the version bumped to 3.1.
... then this last one is a patch file for the configure script. The code is for version 1.6 but to me it looks like the author forgotten to update the version from 1.4 to 1.6 in the configure script. I ahve checked in freechart/ReadMe.txt saying it is verion 1.6 and confirmed that the 1.6 addition of freechart/src/chartsplitpanel.cpp indeed exists.
*** 1,6 ****
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
! # Generated by GNU Autoconf 2.63 for WXFREECHART 1.4.
# Report bugs to <[email protected]>.
--- 1,6 ----
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
! # Generated by GNU Autoconf 2.63 for WXFREECHART 1.6.
# Report bugs to <[email protected]>.
*** 596,603 ****
# Identity of this package.
PACKAGE_NAME='WXFREECHART'
PACKAGE_TARNAME='wxfreechart'
! PACKAGE_VERSION='1.4'
! PACKAGE_STRING='WXFREECHART 1.4'
PACKAGE_BUGREPORT='[email protected]'
ac_subst_vars='LTLIBOBJS
--- 596,603 ----
# Identity of this package.
PACKAGE_NAME='WXFREECHART'
PACKAGE_TARNAME='wxfreechart'
! PACKAGE_VERSION='1.6'
! PACKAGE_STRING='WXFREECHART 1.6'
PACKAGE_BUGREPORT='[email protected]'
ac_subst_vars='LTLIBOBJS
*** 1332,1338 ****
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat <<_ACEOF
! \`configure' configures WXFREECHART 1.4 to adapt to many kinds of systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
--- 1332,1338 ----
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat <<_ACEOF
! \`configure' configures WXFREECHART 1.6 to adapt to many kinds of systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
*** 1398,1404 ****
if test -n "$ac_init_help"; then
case $ac_init_help in
! short | recursive ) echo "Configuration of WXFREECHART 1.4:";;
esac
cat <<\_ACEOF
--- 1398,1404 ----
if test -n "$ac_init_help"; then
case $ac_init_help in
! short | recursive ) echo "Configuration of WXFREECHART 1.6:";;
esac
cat <<\_ACEOF
*** 1506,1512 ****
test -n "$ac_init_help" && exit $ac_status
if $ac_init_version; then
cat <<\_ACEOF
! WXFREECHART configure 1.4
generated by GNU Autoconf 2.63
Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
--- 1506,1512 ----
test -n "$ac_init_help" && exit $ac_status
if $ac_init_version; then
cat <<\_ACEOF
! WXFREECHART configure 1.6
generated by GNU Autoconf 2.63
Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
*** 1520,1526 ****
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
! It was created by WXFREECHART $as_me 1.4, which was
generated by GNU Autoconf 2.63. Invocation command line was
$ $0 $@
--- 1520,1526 ----
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
! It was created by WXFREECHART $as_me 1.6, which was
generated by GNU Autoconf 2.63. Invocation command line was
$ $0 $@
*** 10248,10254 ****
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log="
! This file was extended by WXFREECHART $as_me 1.4, which was
generated by GNU Autoconf 2.63. Invocation command line was
CONFIG_FILES = $CONFIG_FILES
--- 10248,10254 ----
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log="
! This file was extended by WXFREECHART $as_me 1.6, which was
generated by GNU Autoconf 2.63. Invocation command line was
CONFIG_FILES = $CONFIG_FILES
*** 10298,10304 ****
_ACEOF
cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
ac_cs_version="\\
! WXFREECHART config.status 1.4
configured by $0, generated by GNU Autoconf 2.63,
with options \\"`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`\\"
--- 10298,10304 ----
_ACEOF
cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
ac_cs_version="\\
! WXFREECHART config.status 1.6
configured by $0, generated by GNU Autoconf 2.63,
with options \\"`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`\\"
I have used namcap to check the PKGBUILD and the generated freechart-1.6-1-x86_64.pkg.tar.xz. Both passed. However when I use the -i switch, I get a whole bunch of messages. I am quite sure these dependencies do not need to be included in the PKGBUILD. Please correct if I am wrong.
$ namcap -i freechart-1.6-1-x86_64.pkg.tar.xz
freechart I: Link-level dependence (wxgtk) in file ['usr/lib/libwx_baseu-3.0.so.0', 'usr/lib/libwx_gtk2u_aui-3.0.so.0', 'usr/lib/libwx_gtk2u_core-3.0.so.0']
freechart I: Link-level dependence (gcc-libs) in file ['usr/lib/libgcc_s.so.1', 'usr/lib/libstdc++.so.6']
freechart I: Link-level dependence (glibc) in file ['usr/lib/libm.so.6', 'usr/lib/libc.so.6']
freechart I: Symlink (usr/lib/libwxcode_gtk2u_freechart-3.0.so.0) found that points to libwxcode_gtk2u_freechart-3.0.so.0.0.0
freechart I: Symlink (usr/lib/libwxcode_gtk2u_freechart-3.0.so) found that points to libwxcode_gtk2u_freechart-3.0.so.0
freechart I: Dependency covered by dependencies from link dependence (freetype2)
freechart I: Dependency covered by dependencies from link dependence (jasper)
freechart I: Dependency covered by dependencies from link dependence (xextproto)
freechart I: Dependency covered by dependencies from link dependence (gdbm)
freechart I: Dependency covered by dependencies from link dependence (gstreamer0.10-base)
freechart I: Dependency covered by dependencies from link dependence (graphite)
freechart I: Dependency covered by dependencies from link dependence (libcap)
freechart I: Dependency covered by dependencies from link dependence (libx11)
freechart I: Dependency covered by dependencies from link dependence (coreutils)
freechart I: Dependency covered by dependencies from link dependence (shared-mime-info)
freechart I: Dependency covered by dependencies from link dependence (pcre)
freechart I: Dependency covered by dependencies from link dependence (xf86vidmodeproto)
freechart I: Dependency covered by dependencies from link dependence (shadow)
freechart I: Dependency covered by dependencies from link dependence (readline)
freechart I: Dependency covered by dependencies from link dependence (gtk2)
freechart I: Dependency covered by dependencies from link dependence (libxdmcp)
freechart I: Dependency covered by dependencies from link dependence (damageproto)
freechart I: Dependency covered by dependencies from link dependence (dbus)
freechart I: Dependency covered by dependencies from link dependence (avahi)
freechart I: Dependency covered by dependencies from link dependence (cracklib)
freechart I: Dependency covered by dependencies from link dependence (videoproto)
freechart I: Dependency covered by dependencies from link dependence (libsasl)
freechart I: Dependency covered by dependencies from link dependence (libxft)
freechart I: Dependency covered by dependencies from link dependence (libxrandr)
freechart I: Dependency covered by dependencies from link dependence (fontconfig)
freechart I: Dependency covered by dependencies from link dependence (libxdamage)
freechart I: Dependency covered by dependencies from link dependence (acl)
freechart I: Dependency covered by dependencies from link dependence (pixman)
freechart I: Dependency covered by dependencies from link dependence (ncurses)
freechart I: Dependency covered by dependencies from link dependence (libdbus)
freechart I: Dependency covered by dependencies from link dependence (cairo)
freechart I: Dependency covered by dependencies from link dependence (zlib)
freechart I: Dependency covered by dependencies from link dependence (xproto)
freechart I: Dependency covered by dependencies from link dependence (harfbuzz)
freechart I: Dependency covered by dependencies from link dependence (libomxil-bellagio)
freechart I: Dependency covered by dependencies from link dependence (kbproto)
freechart I: Dependency covered by dependencies from link dependence (sh)
freechart I: Dependency covered by dependencies from link dependence (pango)
freechart I: Dependency covered by dependencies from link dependence (pam)
freechart I: Dependency covered by dependencies from link dependence (libxau)
freechart I: Dependency covered by dependencies from link dependence (llvm-libs)
freechart I: Dependency covered by dependencies from link dependence (libxfixes)
freechart I: Dependency covered by dependencies from link dependence (attr)
freechart I: Dependency covered by dependencies from link dependence (mesa-dri)
freechart I: Dependency covered by dependencies from link dependence (libtxc_dxtn)
freechart I: Dependency covered by dependencies from link dependence (xz)
freechart I: Dependency covered by dependencies from link dependence (gdk-pixbuf2)
freechart I: Dependency covered by dependencies from link dependence (elfutils)
freechart I: Dependency covered by dependencies from link dependence (libxv)
freechart I: Dependency covered by dependencies from link dependence (mesa)
freechart I: Dependency covered by dependencies from link dependence (renderproto)
freechart I: Dependency covered by dependencies from link dependence (systemd)
freechart I: Dependency covered by dependencies from link dependence (libxcursor)
freechart I: Dependency covered by dependencies from link dependence (hwids)
freechart I: Dependency covered by dependencies from link dependence (bash)
freechart I: Dependency covered by dependencies from link dependence (glibc)
freechart I: Dependency covered by dependencies from link dependence (expat)
freechart I: Dependency covered by dependencies from link dependence (e2fsprogs)
freechart I: Dependency covered by dependencies from link dependence (linux-api-headers)
freechart I: Dependency covered by dependencies from link dependence (libffi)
freechart I: Dependency covered by dependencies from link dependence (libxi)
freechart I: Dependency covered by dependencies from link dependence (libice)
freechart I: Dependency covered by dependencies from link dependence (libldap)
freechart I: Dependency covered by dependencies from link dependence (libxcomposite)
freechart I: Dependency covered by dependencies from link dependence (libgpg-error)
freechart I: Dependency covered by dependencies from link dependence (libxcb)
freechart I: Dependency covered by dependencies from link dependence (libseccomp)
freechart I: Dependency covered by dependencies from link dependence (keyutils)
freechart I: Dependency covered by dependencies from link dependence (xcb-proto)
freechart I: Dependency covered by dependencies from link dependence (randrproto)
freechart I: Dependency covered by dependencies from link dependence (bzip2)
freechart I: Dependency covered by dependencies from link dependence (libxml2)
freechart I: Dependency covered by dependencies from link dependence (libpciaccess)
freechart I: Dependency covered by dependencies from link dependence (util-linux)
freechart I: Dependency covered by dependencies from link dependence (krb5)
freechart I: Dependency covered by dependencies from link dependence (compositeproto)
freechart I: Dependency covered by dependencies from link dependence (glib2)
freechart I: Dependency covered by dependencies from link dependence (libxinerama)
freechart I: Dependency covered by dependencies from link dependence (gstreamer0.10)
freechart I: Dependency covered by dependencies from link dependence (kbd)
freechart I: Dependency covered by dependencies from link dependence (kmod)
freechart I: Dependency covered by dependencies from link dependence (filesystem)
freechart I: Dependency covered by dependencies from link dependence (libxxf86vm)
freechart I: Dependency covered by dependencies from link dependence (tzdata)
freechart I: Dependency covered by dependencies from link dependence (libsm)
freechart I: Dependency covered by dependencies from link dependence (pambase)
freechart I: Dependency covered by dependencies from link dependence (libcups)
freechart I: Dependency covered by dependencies from link dependence (atk)
freechart I: Dependency covered by dependencies from link dependence (libgl)
freechart I: Dependency covered by dependencies from link dependence (libsystemd)
freechart I: Dependency covered by dependencies from link dependence (xineramaproto)
freechart I: Dependency covered by dependencies from link dependence (lzo)
freechart I: Dependency covered by dependencies from link dependence (orc)
freechart I: Dependency covered by dependencies from link dependence (inputproto)
freechart I: Dependency covered by dependencies from link dependence (libpng)
freechart I: Dependency covered by dependencies from link dependence (db)
freechart I: Dependency covered by dependencies from link dependence (libdatrie)
freechart I: Dependency covered by dependencies from link dependence (fixesproto)
freechart I: Dependency covered by dependencies from link dependence (hicolor-icon-theme)
freechart I: Dependency covered by dependencies from link dependence (gtk-update-icon-cache)
freechart I: Dependency covered by dependencies from link dependence (libjpeg)
freechart I: Dependency covered by dependencies from link dependence (libtirpc)
freechart I: Dependency covered by dependencies from link dependence (gcc-libs)
freechart I: Dependency covered by dependencies from link dependence (openssl)
freechart I: Dependency covered by dependencies from link dependence (gmp)
freechart I: Dependency covered by dependencies from link dependence (libxext)
freechart I: Dependency covered by dependencies from link dependence (iana-etc)
freechart I: Dependency covered by dependencies from link dependence (libutil-linux)
freechart I: Dependency covered by dependencies from link dependence (libthai)
freechart I: Dependency covered by dependencies from link dependence (perl)
freechart I: Dependency covered by dependencies from link dependence (libxrender)
freechart I: Dependency covered by dependencies from link dependence (wayland)
freechart I: Dependency covered by dependencies from link dependence (libtiff)
freechart I: Dependency covered by dependencies from link dependence (libxshmfence)
freechart I: Dependency covered by dependencies from link dependence (libgcrypt)
freechart I: Dependency covered by dependencies from link dependence (libdaemon)
freechart I: Dependency covered by dependencies from link dependence (libdrm)
freechart I: Depends as namcap sees them: depends=(wxgtk)
Many thanks!

Hi it turns out that the SVN version is the most up to date which does not need to be patched as it has the right version numbers. I have created a new PKGBUILD.
# Maintainer: kso <keansum AT gmail DOT com>
pkgname=freechart-svn
pkgver=r3169
pkgrel=1
pkgdesc="Free powerful charting library based on wxWidgets."
arch=('x86_64' 'i686')
url="http://wxcode.sourceforge.net/components/freechart/"
license=('custom:"wxWindows"')
depends=('wxgtk')
makedepends=('subversion')
source=('svn+http://svn.code.sf.net/p/wxcode/code/trunk/wxCode/components/freechart/')
md5sums=('SKIP')
_svntrunk=http://svn.code.sf.net/p/wxcode/code/trunk/wxCode/components/freechart/
_svnmod=freechart
pkgver() {
cd "$_svnmod"
local ver="$(svnversion)"
printf "r%s" "${ver//[[:alpha:]]}"
build() {
cd "$srcdir"
msg "Connecting to SVN server...."
if [[ -d "$_svnmod/.svn" ]]; then
(cd "$_svnmod" && svn up -r "$pkgver")
else
svn co "$_svntrunk" --config-dir ./ -r "$pkgver" "$_svnmod"
fi
msg "SVN checkout done or server timeout"
msg "Starting build..."
rm -rf "$srcdir/$_svnmod-build"
svn export "$srcdir/$_svnmod" "$srcdir/$_svnmod-build"
cd "$srcdir/$_svnmod-build"
# BUILD HERE
./configure --prefix=/usr
make
package() {
cd "$srcdir/$_svnmod-build"
make DESTDIR="$pkgdir/" install
# install LICENSE
install -D -m644 $srcdir/$_svnmod/license.txt "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
I have uploaded onto the AUR. I have checked using namcap. Please let me know if there are any mistakes. Many thanks!

How to find good games/apps in the store besides the public reviews?

Hi all, I'm trying to find good games/apps in the store to put on my 32gig touch. I know about the reviews for the games/apps but with so many negative comments for some, for example F***G c**p, reboots the ipod touch every time I play it or run it for apps (insert Maker's name ere) want a refund don't download & giving it 1 star & the list just goes on, out of the one's I've thought I would either buy or download (for the free one's) I've not even botherd as I think to myself. With so many negative comment's the app/game must be rubbish. Doesn't apple review the comments put on the games/apps reviews?. So is there another way to find out what is good/bad in the app store besides trawling though 95% of negative comments? cheers
Message was edited by: dj-toonz

I tried to follow the instructions using iphone 5. When you get to step 5, swipe your finger over the apps. It won't work. Does anyone have iphone 5 and try to hide unwanted apps sucessuflly. Please share with us. Thanks

Are the JSRs working for the 'public'?

Part of the JCP/JSR review process is a 'public' draft, where anyone can comment on it. Comments on this are then supposed to lead to possible changes in the reference implementation followed up by a final draft and a final acceptance.
1.5 (tiger) is supposed to be released this summer. And JSR 201 which includes autoboxing and a lot of other stuff ( http://jcp.org/en/jsr/detail?id=201 ) is in that. There is a beta (or alpha) program right now for 1.5. Yet 201 is not in the review stage yet. That isn't too unexpected given that they have to work the kinks out. I suspect it just isn't done yet.
However, it does make me wonder what point the 'public review' serves. I doubt that by the time it is released that any comment, other than perhaps documentation changes, will be incorporated. It simply will be too late.
I have reason to believe that at least one other JSR will end up being handled in the same way.
Does anyone else have reason to believe that comments received during a public review of any JSR in 1.5 would result in either a major or even minor change?

To be honest, I am not sure. I considered joining the
JAI experts group (A long while back). It did not
appear to be free. At the very least it requires you
have funding available to attend meetings and work on
the proposals (which tends to limit contributors to
those working for supportive companies). That may
have just been JAI though.In the past it cost - I looked into joining as well.
What I looked at a couple of days ago says there is no cost to join.
I don't know if they have on-site meetings. I figured most of it was electronic.
>
JSR's are evaluated by SUN as to whether they will
provide market share/utility/cost/detrement/whatever
for SUN. If
it does not satisfy thier criteria it does not happen.
(Many JSR's are additional/optional packages so they
don't
generally have these problems). Represenatives and
proposals from larger companies (who
are heavily invested in java) do tend to get more
attention (which is not surprising) especially when it
comes
to changes to critical parts of java.
Interesting point.
The JSR process does not include that (or at least it specifically seems to not be that way) but that doesn't mean that Sun has to implement any JSR. However, as far as I know they have implemented everyone that impacted the JVM/API directly.
>
All in all I've found that if you have a good point
then it will be considered. However, it is often the
case
that it is a good point which has already been made.
I don't know why 1.5 additions have not been opened
for public comment. (Are you sure they haven't
already?)
I am sure that the one I listed has not.

Java EE 5 Web Tier Proposed Final Draft

We're pleased to announce the availability of the Public Review of the next versions of the specifications for the Java Web tier. This includes Servlet, JavaServer Pages (JSP), the JSP Standard Tag Library (JSTL) and JavaServer Faces (Faces). Servlet is being developed under JSR-154, JSP 2.1 is developed under JSR-245, JSTL is developed under JSR-052 and Faces 1.2 is developed under JSR-252. The expert groups are working together to improve the alignment between these these powerful web technologies.
Building on the work that was accomplished with the Early Draft Review, this Public Review covers two additional areas that required better integration between JSP and Faces: - Tree Creation and Content Interweaving - Deferred expressions nested within iteration tags
Please see Appendix E of the JSP spec and the Preface of the Faces spec to see details of what's changed in JSP and Faces. Please see the change-logs for the Servlet and JSTL specs for what's changed in Servlet and JSTL.
To access the specifications:
JSP 2.1 PR (JSR-245)
http://jcp.org/aboutJava/communityprocess/pfd/jsr245/
Faces 1.2 PR (JSR-252)
http://jcp.org/aboutJava/communityprocess/pfd/jsr252/
To access the change-logs
Servlet 2.5 (JSR-154)
http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/index3.html
JSTL 1.2 (JSR-052)
http://jcp.org/aboutJava/communityprocess/maintenance/jsr052/index2.html
Sincerely,
The Web Tier Expert Groups!

Any news on JSR-267?

Welcome to this forum on "Core J2EE Patterns" by the Sun Java Center

Welcome to this forum on Core J2EE Patterns by the Sun Java Center!
CONTEXT:
This forum is intended for discussing the patterns from the Sun Java Center J2EE Pattern Catalog and other topics discussed in our book, Core J2EE Patterns.
We, the authors of the book, welcome you to this forum.
WHO WE ARE:
We are Enterprise Java Architects from the Sun Java Center (SJC), which is the Java consulting organization of Sun Microsystems. We are a world-wide group of architects focusing on all consulting related to Java technologies.
Visit our web-site for more information on SJC:
http://www.sun.com/service/sunps/jdc/index.html
BACKGROUND:
Over the last few years, we at SJC have worked with our customers in architecting, designing, and implementing solutions on the J2EE platform. We have worked on documenting the J2EE patterns for over two years and released the patterns for public review in Beta form via the Java Developer Connection in May, 2001.
The beta version of the patterns is available online as The Sun Java Center J2EE Pattern Catalog at:
http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/
Subsequent to the release, we received great feedback and comments from hundreds of reviewers. We then worked towards incorporating the feedback into the pattern documentation. One of the common comments was about the lack of code examples in the online documentation. The latest pattern documentation provides many code examples and incorporates all the feedback received so far.
BOOK INFORMATION:
Core J2EE Patterns, the book, was released at JavaOne 2001 during June 4-9, and will be available in stores around the end of June 2001.
The book includes the complete updated Sun Java Center J2EE Pattern Catalog with 15 patterns covering these J2EE technologies: Java Server Pages (JSP), Servlets, Enterprise JavaBeans (EJB), and Java Message Service (JMS). In addition to the J2EE Pattern Catalog, the book also provides other chapters that discuss design considerations,
bad practices, and J2EE Refactorings. Example code is included for all patterns and strategies.
If you wish to view the complete table of contents or order the book, please visit one of the following online bookstores:
Fatbrain.com: http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0130648841
Amazon.com: http://www.amazon.com/exec/obidos/ASIN/0130648841
COMMUNITY:
The online community for discussing the patterns included in our book Core J2EE Patterns has grown over the past year, since our first presentation at JavaOne 2000. This community is supported by our LISTSERV and is available for public participation at:
http://archives.java.sun.com/j2eepatterns-interest.html
You can view the past discussions on this list at the above URL.
FORUM LOGISTICS:
John and Dan are on the east coast and Deepak is on the west coast. We will be tuned into the forum and answering the messages periodically between June 19 and June 25, 2001. If you want to discuss the J2EE Patterns after June 25, you are invited to join the aforementioned J2EE Patterns Interest list.
FORUM DISCLAIMER:
All responses to questions posed in this News Group are given on an "as is" basis. We believe the solutions or explanations given here are correct, but do not guarantee that responses will be complete, without error and/or work for all platforms and system configurations.
The forum is now open! Let the discussion begin...
John Crupi - Chief Java Architect
Dan Malks - Enterprise Java Architect
Deepak Alur - Enterprise Java Architect
---Authors of Core J2EE Patterns

Rajakannan,
There are numerous ways to implement a templating mechanism in support of the composite view pattern, included in the catalog as a presentation-tier pattern.
The goal is to avoid simply having monolithic views with all the formatting code embedded directly withing the view. If we have common subviews that are shared across several or more views then we end up with a copy-and-paste type of reuse...undesirable. So, modularity is one issue. Another major force when considering the Composite View pattern is that we may want to manage the layout of our pages and the content of our pages separately. We may have some logical regions defined, such as a search panel and main body, and a subview that plugs into those logical regions that map to a physical page (ie: x.jsp and y.jsp). We may then want to vary one independent of the other...ie: we may want to modify the layout of the page w/o changing the content and we may want to vary the content w/o touching the layout.
There are a number of implementation strategies that can be used to implement the Composite View pattern, ranging from relatively simple to much more sophisticated. We describe each in our book and include source code examples.
The example in the book that allows for supporting all the issues described above is implemented using the "Custom Tag View Management Strategy" and uses a tag library written by David Geary, that supports the Composite View pattern. The library is also included in David's new book, Adv. JavaServer Pages, Prentice Hall, 2001.
Again, it's simply one implementation and, as you mention, there are many different ways to implement this strategy.
Thanks for your question,
Dan

Applet On Netscape and IE

We are building a shopping cart applet using jdk1.0.x
When the user clicks on a submit button applet makes a connection to the server and waits for the server response. This piece of code makes a status message visible while the applet is waiting for server response.
public boolean mouseDown(Event event,int x, int y)
if (y >= 235 && y <= 260 && x >= 433 && x<= 511 )
lMessage.setVisible(true);
parent.SubmitInfo();
parent.Confirmation(); // make next page visible
return true;
The message is visible in Netscape , but in IE (both in MAC and Windows) it does not show up.
Does anyone have any ideas ?
Thanks in advance
Syama.

Hi, Guess I should have given code sample. lMessage is a label and it is added to the panel.
It does not display on IE but it displays on Netscape.
public class Review extends Panel
// members
public Review(ECommerce _parent)
// add size other components
     add(lMessage);
     lMessage.reshape(10,240,300,20);
     lMessage.setFont(parent.mFB);
     lMessage.setBackground(parent.bC);
     lMessage.setForeground(parent.mtC);
     lMessage.setVisible(true);
// other methods none of them refer lMessage
public boolean mouseDown(Event event,int x, int y)
     if (parent.submitOrder) return true;
     if (y >= 235 && y <= 260 && x >= 433 && x<= 511 )
          parent.submitOrder = true;
                         lMessage.setVisible(true);
     lMessage.requestFocus();
     repaint();
     parent.SubmitInfo();
     parent.Confirmation();
     parent.submitOrder = false;
     return true;
May be it has something to do with jdk - we are using jdk 1.1.
Thanks,
Syama.

Simple CMS in Flash CS5

I am building a site for a local county government. Certain departments post documents from time to time for public review. For example our Human Resources department post jobs frequently. They would like to have the ability to post these jobs on there own, with no help from me the web developer. So I guess what I am looking for is a method of setting up a form so that certain people can fill out descriptions then upload and actual PDF as well. They will all so need the ability to remove the upload after a certain amount of time. Any thoughts?

using xml is a good way to supply a limited amount of data to flash. you can create an xml editor that will allow others to update the xml file and protect it from people that don't understand xml encoding.

Anomymous Commenting

I recently started an all PDF Blog
http://www.math.uakron.edu/~dpstory/pdfblog.html
A copy of each "PDF Blog" is uploaded for shared review to
Acrobat.com. My concern is about privacy. This is a "public"
review, perhaps not
envisioned. Anyone who comments must have an Adobe ID, no
problem,
but their email is exposed by Tracker to anyone who comments
on the
document. I thought of setting up a "dummy" Adobe ID account,
[email protected] with a password of guest (or something).
On my
blog, I would encourage individuals to login with this Adobe
ID.
This might be viewed as an abuse of the system. What do you
think?
The dummy Adobe ID would set up 5GB of space on Acorbat.com
that
anyone who visits my page would have access to, and the
"guests"
may change the password. This would probably
not be good. Is it possible to set up an Adobe ID, in this
way,
without allocation of the Acrobat.com privileges, (including
changing of username and passwords),
other than commenting?
Is there another solution?
Any suggestions?
I would like to use Acrobat.com for this "innovative" blog as
part
of the commenting system.
Regards, D. P. Story

Hi Donald,
Thanks for the feedback. We are glad to see you using Acrobat
and the Acrobat.com service for your blog.
The specific use-case that you have identified i.e. a public
review is however currently not supported by Acrobat. The intent of
the Acrobat Shared Review was to allow a group of identified
individuals to be able to comment on a document. Since these
comments are visible to everyone participating in the review, it is
important for the participants to be able to identify the source of
any comments on the documents to facility open/effective
collaboration. The use-case you describe is quite unique and we
haven't heard similar requirements from other Acrobat.com users. I
will forward your feedback to the team that works on the Acrobat
product so that they might consider this in their list of features
for the next release of Acrobat.
In addition, I do have one suggestion for your blog.
Acrobat.com will allow you to embed documents into your blog, this
will provide a much richer visual view of the PDF document for the
reader of your blog and allow them to download the document from
there.
An example of an embedded PDF can be found on the
Acrobat.com
Blog
To embed your document into your blog, you have to simply
copy the Embed Code for the document through the UI and then add it
to your blog.
The "
How
do I share a file in a web page" section of the help has more
detailed information about this topic.
Let me know if you have any additional questions. Would love
to hear from you if you think the embedded documents will work for
you.
Regards
The Acrobat.com team

Bookmarking JSF pages

Hi All
there was discussion about bookmarking JSF pages some time ago.
This problem really bothers me. There was opinion that you shouldn't use JSF for pages you need to bookmark... but it's quite inconvinient if you should implement part of web application in one framework and another part in different framework.
Is there any new opinions/ideas about this issue?
I've been thinking about converting request to GET redirect using simple JSP page... but in this case session info will be lost I believe.

It depends of the site design (ergonomics) and end user experience.
There is a special section on the http://jsfTutorials.net that is dedicated to Struts - "JSF vs. Struts, JSF with Struts". Actually, it reflects how the standpoint is changed for the last one year.
Regarding JSP and JSTL: It is a temporaty situation. JSP and JSF expert groups work together to eliminate the problematic issues. The final draft for JSP 2.1 and JSF 1.2 specifications are already available for public review.
There is a very interesting framework - facelets ( https://facelets.dev.java.net/ ) that utilizes the new benifits already. Facelets works on top of the JSF.
Sergey : http://jsfTutorials.net

Public Review of SKSML v1.0

Similar Messages

Maybe you are looking for