Question about project names.
Hi. I'm the author of MINA (Multipurpose Infrastructure for Network Applications) subproject in Apache Directory project. We are checking our project names before releasing them. I checked the name 'MINA', and I found three trademark holders. None of them are software or IT companies. I found two non-US companis whose names are 'Mina software' and 'MINA systems' and Forth language interpreter called 'Mina.com'. I want to know it would be OK if I use the name MINA. I've been thinking it is OK ecause MINA is just a girl's name and means 'south' in Japanese. It is also just a girl's name in South Korea. Thanks in advance for helps. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Directory project releases II
+1 :) On Tue, 28 Dec 2004 21:38:22 -0500, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Hello again, > > It looks like lots of people are away and we're going to have to wait > for some clarification on whether or not we can release kerberos, eve, > janus, and seda as is or change their names. So in the mean time I > think we can separately release the following: > > ldap (0.8) > - common LDAP libraries > - > http://incubator.apache.org/directory/subprojects/directory-ldap/index.html > > naming (0.8) > - a lightweight, in-memory JNDI service provider > - > http://incubator.apache.org/directory/subprojects/directory-naming/index.html > > asn1 (0.2) [previously called snickers] > - high performance non-blocking replacement for the Snacc4J runtime > (ASN.1 runtime) > - http://incubator.apache.org/directory/subprojects/asn1/index.html > > Note: > > Snickers has been renamed to the Apache ASN.1 project. ASN, ASN.1, "ASN > One" all are not trademarked. The website has been updated as well as > all the code within the directory project that depends on this code. > Package names have been changed as well. There is no trace of Snickers > anymore. > > [ ] +1 Approve the request to release > [ ] -1 Reject the request to release > [ ] +0 Abstain > > Again have a Happy New Year! > The Directory Project Team > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- what we call human nature is actually human habit -- http://gleamynode.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Directory project releases
Roy, how do you think about the name MINA? I think you saw the question I posted a couple of days ago. I need your advice, too. :) Thanks in advance. Trustin On Thu, 30 Dec 2004 14:29:19 -0800, Roy T. Fielding <[EMAIL PROTECTED]> wrote: > > Niclas Hedhman wrote: > >> Janus is "God of Gates and Doorways" and a moon of Saturn was named > >> after him in 1966. > >> http://solarsystem.nasa.gov/planets/profile.cfm?Object=Sat_Janus > >> > >> The sited web page is about arbitration of a domain name and to > >> regain control of such domain name. Janus Capital Group does not seem > >> to go after every use of Janus, so it is not a matter of trademark > >> issue; > >> http://www.janus-software.com/ > >> http://www-odp.tamu.edu/database/ > >> http://www.janus-eu.org/Temp2/index-f.htm > >> http://www.janusassociates.com/ > >> http://www.janusdevelopment.com/ > > No, that is not how trademark law works. It doesn't matter how common > the > name may be -- what matters is whether the name is distinctive within a > given category of use (keeping in mind that these folks are on the > Internet > as well) such that they may have grounds for filing suit on the basis > of us > confusing their consumers. I didn't say that they would need to win > that suit. > > My point was that the Janus name, like those of all Greek/Roman gods, > is already being used by a dozen or so software projects, including some > open source ones, in addition to there being a wealthy litigation firm > concerned about use of the name on the Internet. > > Using Janus as a name for a new product is therefore unwise. > > Roy > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- what we call human nature is actually human habit -- http://gleamynode.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][release] [ApacheDS] 0.8
> --- > [x] +1 I support this release and am willing to help > [ ] +0 I support this release but am unable to help > [ ] -0 I do not support this release > [ ] -1 I do not support this release, and here are my reasons > --- Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Volunteer Documentation
Hi Vikas, On Thu, 17 Mar 2005 09:17:25 +0530, Vikas Singhal <[EMAIL PROTECTED]> wrote: > Hi List, > > I am a technical writer with an experience of more than three years. I want > to contribute to the foundation in terms of documentation. Wow, it would be really nice to see your contribution! > I am willing to work on projects that either have no documentation or > minimal documentation. Can anyone help me in identifying such projects? I'm a PMC of the Apache Directory Project which is an effort to make the best-of-the breed LDAP server and X.500 experimentation platform. We're close to the release of version 0.9, our documentation is still premature. It would be really nice and cool to see your contribution and we'll appreciate it. ;) Here's the URL: http://directory.apache.org/ Please feel free to look around! Thanks, Trustin. -- what we call human nature is actually human habit -- http://gleamynode.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project Proposal: Subvertive
+1. Looks very interesting! Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: [ftpserver] Contributing to FTPServr
Hi Sanjiva, 2005/8/16, Sanjiva Weerawarana <[EMAIL PROTECTED]>: > > Is there an HTTP impl on top of MINA? I'd love to get that to build a > standalone framework for Axis2 (ideally with Spring). Yes, HTTP server example is included in MINA distribution. But it is very simplistic, so you'll need to modify and test it under heavy load. MINA is known to work fine with Spring and any other IoC frameworks. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: proposal for an ESB/broker project: Synapse
Hi Noel, 2005/8/16, Noel J. Bergman <[EMAIL PROTECTED]>: > > Sanjiva Weerawarana wrote: > > > > If the WS PMC has voted to incubate this project, you should be good > to > go. > > Oh! Don't we still need a vote? > > If a PMC votes to submit a project for incubation, the Incubator PMC does > not vote; the project is accepted, and the mentors are added to the > Incubator PMC. I didn't know that. Thanks for clarification. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: [ftpserver] Contributing to FTPServr
Hi Niklas, 2005/8/17, Niklas Gustavsson <[EMAIL PROTECTED]>: > > But, do you think that Apache Directory Server/MINA would be a > appropriate home for a fully fledged FTP server? I would imagine it's > beyond their scope. Of course MINA could provide codecs for popular protocols like FTP and SMTP out-of-the-box. It will take MINA to the level of full-featured client/server development platform. We also could provide visual protocol design tool which closely integrates with Apache ASN.1 codec. Can you imagine that? Actually I'm thinking about proposing this to Incubator project. :) But you can, of course, just use MINA to program FTP server and provide it as a separate project. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: [Ftpserver] Open Issues in Jira
Hi Rana, You'd better e-mail the persons who created those issues directly in case they have unsubscribed from the list. Most ppl was helpful to close all of issues for DIRMINA. :) HTH, Trustin 2005/10/6, Rana Bhattacharyya <[EMAIL PROTECTED]>: > > Hi, > > Myself and Sergey Vladimirov do not have permissions > to close issues in Jira. Can someone please close the > following issues. > > FTPSERVER-18 > FTPSERVER-16 > FTPSERVER-14 > FTPSERVER-13 > FTPSERVER-12 > FTPSERVER-5 > FTPSERVER-4 > > Thanks, > Rana Bhattacharyya > > > > __ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: [Ftpserver] Open Issues in Jira
Hi Rana, 2005/10/6, Rana Bhattacharyya <[EMAIL PROTECTED]>: > > Unfortunately, the persons who created those issues > have the user access not the developer access. So they > won't be able to close those issues. I thought that only admins can close the issues at the first time, but I saw many normal users close their issues that I couldn't close even if I'm the admin of the project. Can anyone clarify this? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: Adding a new Project on Jakarta
Hello Joao, 2005/10/13, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > The JFTP4I is a new idea for the concept of using FTP for integration > purposes. Here in Brasil (and i think very much in the rest of the world), > all the legacy systems are basically using FTP as a way of integrating > different platforms running under TCP/IP. Example: we have a lot of cases > of programs running in the mainframe that are actually using FTP to > transmit data to the lower-platform. The JFTP4I is actually an application > server that can support a number of deployed application inside the FTP > engine. A general flow will be: The user(system) makes a put (or read) > file request to the JFTP4I, the FTP engine then recognizes (using the XML > configuration file) the actual FTPAction to be executed, and then > delegates the flow to the right method inside the action - The framework > uses the PODA/MVC II patterns, and is very similar to the Jakarta Struts > framework (request -> controller -> Action). This framework can do a lot > of things, like generate files dinamically (files that do not actually > exist on disk, files that are created dinamically), implement personalized > responses between systems, manage a secure exchange of files using > detailed transactions, trace, and so forth. Sounds very interesting and it is similar to what was in our MINA roadmap. MINA project team will provide protocol handlers for well-known protocols such FTP, HTTP, and SMTP on top of MINA. I guess your team has implemented it without any network framework. It could be much better if we cooperate. And perhaps we could cooperate with 'ftpserver' team who is already in incubation. Please take a look around MINA web site: http://directory.apache.org/subprojects/network/ 'Getting Started' section will provide you enough information. It would be great if you let me know what you think. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: Adding a new Project on Jakarta
Hi Joao 2005/10/14, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > >Sounds very interesting and it is similar to what was in our MINA > roadmap. > >MINA project team will provide protocol handlers for well-known protocols > >such FTP, HTTP, and SMTP on top of MINA. I guess your team has > implemented > >it without any network framework. It could be much better if we > cooperate. > >And perhaps we could cooperate with 'ftpserver' team who is already in > >incubation. > > I love the idea, how can we organize this? Yes () we had implemented > the standart FTP commands :-P(PI and DTP) defined in the rfc959, just i > nightmare to understand and use. Maybe we can join forces, why not. OK, it sounds like you're interested enough. Then what about contributing your team's work by providing us some patches? It will help us to considering letting you and your team in to us. WDYT, Noel? Would there be any issue with doing this? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: storing documentation in Subversion
Hello David, 2005/12/20, David Crossley <[EMAIL PROTECTED]>: > > This is a topic that i often hear, not only at new projects. > People are not sure what needs to be stored in svn and why. > > A while ago, Noel raised the issue on the infra@ list. [1] > Unfortunately not much follow-up. So i wonder if we can > resolve it here and then document the outcome. This is an interesting issue, and I think it has to be resolved. Sorry that there were no many follow-ups. > The current operating principle is that we store all > source content in the official revision control system. > Some people have said that that is a dictate. > > That includes everything: code, configuration files, > source content for docs, letters received, meeting minutes, > logos, everything. What I cannot understand is 'why ASF infra team is providing wiki' if we have to store all source content in the official RCS? Does this mean what we documented in wiki can cause a problem? We also store generated documentation in SVN. > This makes it very easy to restore or replicate > the websites. This has been always a good idea, but I guess some projects are not using this technique for now. For example, the projects which uses Maven as a build tool look like deploy the site to the filesystem directly. It would be great if there's some standardized tool many build tools support. Otherwise, is this issue just for Ant and Maven, or should site publishing be done manually using 'svn' or 'cvs' command?) With the advent of new documentation management tools > (e.g. Lenya, JackRabbit, Daisy) and their potential > use by ASF projects for their project documentation, > we are seeing questions about how to enable the > storage of the sources for documentation. I always have imagined a web-based wiki application which stores its data in a certain directory in SVN repository. Perhaps, we could create this kind of backend extension for our existing CMS. Similarily, storing bugs and issues information could be stored in SVN repository, all in human readable text format. Yes, this takes a lot of time. Am I talking too ideally? :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: Incubator Guidelines Documentation
Hi all, 2005/12/18, David Crossley <[EMAIL PROTECTED]>: > > Noel J. Bergman wrote: > > Jean Anderson and Eddie O'Neil have volunteered to help redact our > collected > > wisdom into a coherent guide. Cliff Schmidt will contribute on the > legal/IP > > side. Henri Yandell has volunteered to review as a guinea pig. > > > > Anyone who wishes to volunteer is welcomed. We'll want to get input > from > > those who have gone through the process, those who are considering it, > and > > from other groups within the ASF, such as the PRC. > > > > If there is sufficient interest, we can create a mailing list for > managing > > the process, else we can do it here. Do we want a specific mailing > list? > > Keep it here on general@ please. The discussion will assist > everyone to know the process and help to refine it. +1 I'd like to review it, too. :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ PGP Key ID: 0x854B996C
Re: storing documentation in Subversion
2005/12/20, Ross Gardler <[EMAIL PROTECTED]>: > > I always have imagined a web-based wiki application which stores its > data in > > a certain directory in SVN repository. Perhaps, we could create this > kind > > of backend extension for our existing CMS. > > The problem is that we are unlikely to be able to create a solution that > suits everyone. As I understand it infra don't care how the > documentation is created as long as they can easily maintain the > publishing framework, the ASF requirements for traceability are met and > they are not expected support a wide range of CMS systems. > > Sadly, everyone wants to use their own system (even within projects > there is not always agreement). With the creation of zones for TLP's it > is now possible for projects to "go it alone" using whatever CMS they > want with whatever back-end they want (this has already happened in at > least one project). > > This could cause huge problems for infra - we have to come up with a > solution *before* it becomes an unmaintainable problem. But how? If the ASF requirements for traceability is a must, I think we have to sacrifice individual preferences at least a little bit for the infra team. Tools such as Trac (http://www.edgewall.com/trac/) is very impressive from the viewpoint of traceability, but it's not mature yet. We need to find the gem we can really use for full traceability and integration between various sources (i.e. wiki, issue tracker, source code repository, mailing list, ...). > Similarily, storing bugs and > > issues information could be stored in SVN repository, all in human > readable > > text format. Yes, this takes a lot of time. Am I talking too ideally? > :) > > That's an interesting point. Issue tracking is another artifact that is > not stored in SVN. Would it be useful to explore the justification for > this? Storing issues in SVN repository actually sounds similar with storing mailing list archives in SVN repository. It is too ideal. What we need is perhaps a CMS which combines: * site management (support for both production/draft(wiki?)) * issue tracker * source code repository viewer * mailing list + forum (like www.nabble.com does) And if we store all documentation in the CMS, we'll need a tool that fetches the whole site and includes it into binary distributions. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ PGP Key ID: 0x854B996C
Re: Lists set up for Yoko podling
I sent subscription messages to yoko-commits-subscribe, yoko-dev-subscribe, and yoko-user-subscribe, but the server returned them saying that there's no such mail boxes. Is it really set up? Trustin On 2/22/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Infrastructure.. > > As one of the mentors of the Yoko podling, I request > the creation of the following mailing lists for the podling: > > Name: [EMAIL PROTECTED] > Archives: public, Eyebrowse > Moderators: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > > Name: [EMAIL PROTECTED] > Archives: public, Eyebrowse > Moderators: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > > Name: [EMAIL PROTECTED] > Archives: public, Eyebrowse > Moderators: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > > Name: [EMAIL PROTECTED] > Archives: private > Moderators: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > > Thanks! > - -- > #kenP-)} > > Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ > Author, developer, opinionist http://Apache-Server.Com/ > > "Millennium hand and shrimp!" > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iQCVAwUBQ/t/c5rNPMCpn3XdAQLW2wP+IS/ECQiNrFLnnxldnD1s/AYPLnues9z8 > PA62feNxoANiAQaT8G/BHGyNemT5jsPxYCwMhdaRTwrDf3I3fpQTPzWGJThG6Olk > ajd46XxsPEnC3M3gQKjKooZ2L7lNe6VA3wfFMosT8MJw8MLimoN15QnpvvQSwjJ+ > Hb6LF1Oc5lU= > =gR5B > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Lists set up for Yoko podling
On 2/22/06, Garrett Rooney <[EMAIL PROTECTED]> wrote: > > On 2/21/06, Trustin Lee <[EMAIL PROTECTED]> wrote: > > I sent subscription messages to yoko-commits-subscribe, > yoko-dev-subscribe, > > and yoko-user-subscribe, but the server returned them saying that > there's no > > such mail boxes. Is it really set up? > > Uhh, did you see the "I request" at the beginning of Ken's email? I > imagine that when an apmail person gets around to setting them up > they'll reply with some indication that they're up and running ;-) Oops! Perhaps I lost my focus this early morning thanks to my empty tea box. ;) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Cayenne ASF Proposal
Hi Thomas! It has been a long time since we met at ApacheCon US 2005. :) On 2/26/06, Thomas Dudziak <[EMAIL PROTECTED]> wrote: > > On 2/25/06, Brian McCallister <[EMAIL PROTECTED]> wrote: > > Andrus and Bill initially opened discussion on [EMAIL PROTECTED] I > > suggested they aim for a top level project status for a few reasons: > > > > * Cayenne already has an mature ASF-style structure and community > > (reportedly =) > > * There are ~subprojects (the gui tool, etc) in Cayenne, and sub-sub- > > projects seem to be frowned upon > > * DB is getting kind of umbrella shaped already > > > > That said, I am very willing to broach the subject of sponsorship > > with the DB PMC, I just figure the discussion of the best way to > > proceed makes more sense here. I think that Cayenne would prefer to > > be a top level project, in the end, and I agree with that goal. The > > best way to help that happen... well, we're discussing all that =) > > Personally, I'd prefer to have Cayenne in DB rather than as a separate > TLP, mainly for communication reasons with DB-related projects. E.g. I > don't see that much communication between the DB projects and, say, > iBatis or the Geronimo DB stuff (thuogh that might be because I'm not > actively involved in all DB projects). And IMO DB being an umbrella is > quite a different thing than for instance Jakarta, though that's > another issue. > > That being said, whether Cayenne will be a TLP or a DB subproject is > not important until it graduates from incubation, right ? And I'm +1 > on incubating it with the DB PMC as sponsor. Here's my +1. Makes perfect sense. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [VOTE] accept Cayenne into incubator
+1 (non-binding) Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
[IP CLEARANCE] AsyncWeb Software contribution from LogicaCMG Wireless Networks BV
Hi community, The MINA project has received a contribution of the AsyncWeb Software from LogicaCMG Wireless Networks BV. * The IP Clearance form has been committed to the trunk: http://svn.apache.org/repos/asf/incubator/public/trunk/site-publish/ip-clearance/mina-asyncweb.html Please help us verify that everything is in order. The clearance passes by lazy consensus if no -1 votes are cast within the next 72 hours. Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[IP CLEARANCE] KeepAliveFilters.zip contribution from Indagon Oy
Hi community, The MINA project has received a contribution of the KeepAliveFilters.zip from Indagon Oy. * The IP Clearance form has been committed to the trunk: http://svn.apache.org/repos/asf/incubator/public/trunk/site-publish/ip-clearance/mina-keepalive.html Please help us verify that everything is in order. The clearance passes by lazy consensus if no -1 votes are cast within the next 72 hours. Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP Clearance Without A Software Grant [WAS Re: [IP CLEARANCE] KeepAliveFilters.zip contribution from Indagon Oy]
Hi, In case you have missed something, the software grant for KeepAliveFilters.zip has been received. I double-checked grants.txt. Trustin On 10/18/07, Justin Erenkrantz <[EMAIL PROTECTED]> wrote: > On 10/17/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > (this is a good example of something that i've been thinking about > > raising for a little while. it arises from some of the analysis i've > > been doing for RAT.) > > > > this doesn't seem to actually track a software grant but a donation > > through JIRA using AL2.0, section 7. > > > > the current IP clearance page > > (http://incubator.apache.org/ip-clearance/index.html) seems to me to > > be targeted at ensuring that software grants are fully documented. > > this is little at odds with: > > > > "Any code that was developed outside of the ASF SVN repository and our > > public mailing lists must be processed like this, even if the external > > developer is already an ASF committer." > > > > IMO this can be read as implying that projects should use the IP > > clearance when committing anything which isn't the original work of a > > committer > > That wasn't developed through the mailing lists and through our normal > procedures. That is, if it was developed externally, then the IP > clearance form is required. > > > i'm a little unclear about the role of the incubator > > > > opinions? > > The Incubator receives this paperwork on behalf of the ASF. > > But, perhaps I'm not clear what your concern is. -- justin > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Jabber Server
On 10/31/07, Bernd Fondermann <[EMAIL PROTECTED]> wrote: > On 10/30/07, Deepal jayasinghe <[EMAIL PROTECTED]> wrote: > > Petar Tahchiev wrote: > > > Hi guys, > > > > > > today I was looking for a Jabber server implemented entirely in Java, > > > and the only results > > > that I got was this: > > > > > > ---(free)--- > > > http://www.codecobra.com/chime/ > > > http://www.open-im.net/ > > > http://www.tigase.org/ > > > http://www.igniterealtime.org/projects/openfire/index.jsp > > > > > > (commercial)--- > > > http://www.adobe.com/special/antepo/?products.opnserver (no longer > > > available - bought by Adobe) > > > > > > Does anyone (besides me) think that we can build something better? > > > > > > Waiting for your suggestions. > > > > > I also like to contribute to this , if you are going to implement. > > sometimes ago I wanted to build a Jabber (XMPP) implementation based > > Stax implementation. May be this is a good chance for that. > > I'd like to invite you to contribute to Apache Lab Vysper. I had to > implement (reinvent) a XML streaming parser, because those available > didn't quite fit (for various reasons). But that's probably due to my > lack of expertise in this field. There is still high need for a 'real' > XML parser. So, if you have some cycles to spare, help out there. Is Vysper using MINA? I saw a few commit logs related with MINA if I missed something. BTW Openfire team also uses MINA as their networking layer. Please don't hesitate to contact the MINA team whenever you have something to say, ask or rant. :) Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP clearance for contributed code
Hi Richard, IIUC, yes, the owner of the donated code needs to update the source code. Probably you could send some patch to him and he could apply the patch. When I import AsyncWeb, I just did it by myself because I was a committer of the project. Someone please correct me if I am wrong. HTH, Trustin On Jan 24, 2008 1:28 AM, Richard S. Hall <[EMAIL PROTECTED]> wrote: > I am performing the IP clearance paperwork for some code from Peter > Kriens. The IP clearance form here: > > http://incubator.apache.org/ip-clearance/ip-clearance-template.html > > Asks me to fill in the date for: > > Check and make sure that the files that have been donated have been > updated to reflect the new ASF copyright. > > The donated code currently does not have ASF copyright, it has Peter's > copyright. Is the implication here that Peter is supposed to change the > copyright on all source files? I assumed that we would just modify the > source files to have the proper header as part of bringing them into our > repo, but this implies that this must be done beforehand. > > Which is the case? > > Thanks. > > -> richard > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can i start the election?
It is encouraged to start some discussion first before starting a vote, to reach to some consensus in the community. 2008-03-18 (화), 09:07 +0900, edward yoon 쓰시길: > Hello, incubator. > > I made a Hama Proposal. So, I wonder how can i start the election? > Thanks. -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Re: [VOTE] Accept Hama into the Incubator
On Mon, 19 May 2008 17:52:47 +0900, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: Seems like Brett Porter is volunteering, see the other "Mentor recruit for Hama project" thread, with this the issue would be solved IMHO. And he forgot to vote here. Oh well, is it possible to be a mentor not casting a vote? Brett, hurry up! ;) -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 'protocols' sub-module of MINA
On 7/4/06, peter royal <[EMAIL PROTECTED]> wrote: On Jul 3, 2006, at 11:17 AM, Irving, Dave wrote: >> So, my proposal is, how about we start creating module(s) in >> MINA for protocols? >> > > Of course, Im biased - but It would be a shame if we re-wrote http > support on top of Mina over again, when we have asyncweb already :o) > We were originally going to make asyncweb a subproject of mina, but at > the time it was decided it would be cleaner to keep it as a separate > project. Right, it certainly would be a shame. Interested in bringing AsyncWeb over here? :) Bringing in AsyncWeb and other possible future contributions will make this project quite too big to fit into a subproject. We might need an incubation process to find a better place for MINA eventually. Any idea? I will CC this message to [EMAIL PROTECTED] I think that if it lived w/MINA, it might get more help staying up-to- date with our API changes. I agree with you. :) Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [pre-proposal] AsyncWeb
On 7/17/06, peter royal <[EMAIL PROTECTED]> wrote: On Jul 17, 2006, at 5:31 AM, Dave Irving wrote: > One thing I would like to discuss though is identity > AsyncWeb currently has some form of identity in its own right as a > project > (and is already bundled as a standalone http transport in a couple > of OSS > projects). Is this likely to be affected by a move to a Mina TLP? > E.g, Mina > currently has its own identity within the Directory project. Are we > talking > about a similar set up here? I was thinking of a similar relationship to MINA and Directory.. AsyncWeb would *not* be renamed MINA HTTP. AsyncWeb is a great name. Why should we rename it? :) One possibility though could be that MINA HTTP codec provides only encoder and decoder implementation for HTTP messages and AsyncWeb is built on top of it to provide more tighter integration with existing webapp frameworks and more HTTP-friently asynchronous APIs. Yep, this is just an imagination in my brain. We can talk about this step by step. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [pre-proposal] AsyncWeb
On 7/17/06, Dave Irving <[EMAIL PROTECTED]> wrote: Trustin Lee wrote: > > One possibility though could be that MINA HTTP codec provides only encoder > and decoder implementation for HTTP messages and AsyncWeb is built on top > of > it to provide more tighter integration with existing webapp frameworks and > more HTTP-friently asynchronous APIs. Yep, this is just an imagination in > my brain. We can talk about this step by step. > One of the main goals of asyncweb is to provide maximum flexibility when dealing with http services - to satisfy a wide range of usage scenarios. Even though there is still much to do, in the future it will be possible to hook in to all stages of the message reading / writing processes. This allows things like proper (application level) handling of continuation responses, async streaming of large message bodies etc. So I think in the future the asyncweb API is likely to become more generic and flexible to allow the best possible integration with any application requiring high throughput http (e.g, web service frameworks etc). It makes total sense. I'd love to see everything becomes real, though we need to draw a line between generalization and specialization when we generalize AsyncWeb because MINA already has its role to provide a generic network application framework. Of course, if this is possible to achieve whilst factoring out and building upon some lower level http codecs, then that would be awseome! I guess the details of such a refactoring will become more obvious over time after we integrate. Yes, that's my point. We will see as we integrate. I believe this is the Apache way a community grows up healthy, sound and sustainable, like a bottle of great wine. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [VOTE] graduate Solr to Lucene
+1 Looks great to me, and it will be a great addition to the Lucene project. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [proposal] TripleSoup - a SPARQL endpoint for httpd
On 1/30/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: On 1/29/07, Leo Simons <[EMAIL PROTECTED]> wrote: > ...This is a proposal to start a rdf database server project at apache. > > What do you think?.. /me thinks: go ahead! +1 here, too. I am so excited just imagining storing Dublin Core based data! Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [DISCUSS]Incubator podling mvn pom files...
Hi, 2007-02-22 (목), 05:08 -0500, Daniel Kulp 쓰시길: > While looking at the Trinidad stuff, I had some thoughts about requirements > around pom files for Apache stuff and what "requirements" should be imposed. > > There are several things in a pom file that could affect how things appear > when someone takes a dependency on an Apache project. Thus, we need to make > sure these things are correct: > > 1) organization element: Somewhere up the heirarchy, we need to have: > > The Apache Software Foundation > http://www.apache.org/ > Shouldn't we specify http://incubator.apache.org/ for incubator project to state it's an incubator project? I agree with the idea on extending a parent POM generally, but org.apache:apache-incubator might be more reasonable for the projects under incubation. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 signature.asc Description: This is a digitally signed message part
Re: Any potential ideas to start a new Project
On 3/17/07, ambi ambi <[EMAIL PROTECTED]> wrote: Hi, I am looking for some potential ideas to start a new project. Any suggestions? The question is too vague. Are you a committer? Is there any relationship between your new project and the Apache projects? Why do you want to start the new project here? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DNS Protocol (Was: DHCP Protocol Home)
On 6/19/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> What if there were a "frequently updated" dnsjava, containing all of the >> useful community-contributed patches (including dnsjnio), released >> under a >> BSD license - would that be a good solution? > > Absolutely. That is the best of the best IMHO. WDYT guys? Sorry but I don't understand the proposed scenario. I think the problem is that we need a community around a new dns project because we want to provide fast respose and more evolution than dnsjava currently offer. It is true if Brian doesn't have any will to work closely with us. He's not replying to us so far, so I agree with you. And I don't think what Alex is suggesting to us is not so far from what we have been discussing. He didn't say it should be outside of the ASF. ;) What about the "frequently updated dnsjava" you talk about? Who will do that? In what environment? What community? As it has been proposed to be BSD then it cannot be hosted by ASF because the Apache Foundation will only create/maintain ASLv2 projects (and will also need copyrights for everything maintained). Indeed, I really would like to know whether Brian has objections to such an effort, what would be his own preferences about dependencies (or evolutions) of his code, if he would be interested in collaborating in a more "community oriented" project, if he would be interested in an oversight role. dnsjava is licensed under BSD-license, so we can fork it without prior permission, though we need to try. (But he's not responding.) And starting from the ADS DNS protocol provider is also a good idea. I am not a DNS expert so it's up to the actual contributor of the project. If Alex is interested, it's a great news, and starting the project from the incubator might be a better idea to attract more interested non-committers such as Alex. Even if we have little code base so far, we could discuss about this project with the incubator PMC and ask if we can start from existing code that we didn't write (dnsjava) due to its inactivity. BTW, MINA PMC needs to discuss about hosting the project again because we are split into two opinions; to host it at Lab or under MINA. These two options got the same vote count, so I have no idea what to do right now. I started to think it's better to discuss first with the incubator PMC. Let me CC [EMAIL PROTECTED] to find out what people think about it. The whole thread can be browsed here: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02835.html Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DNS Protocol (Was: DHCP Protocol Home)
Hi Brian, On 6/20/07, Brian Wellington <[EMAIL PROTECTED]> wrote: On Tue, 19 Jun 2007, Trustin Lee wrote: > On 6/19/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> >> What if there were a "frequently updated" dnsjava, containing all of the >> >> useful community-contributed patches (including dnsjnio), released >> >> under a >> >> BSD license - would that be a good solution? >> > >> > Absolutely. That is the best of the best IMHO. WDYT guys? >> >> Sorry but I don't understand the proposed scenario. >> >> I think the problem is that we need a community around a new dns project >> because we want to provide fast respose and more evolution than dnsjava >> currently offer. > > It is true if Brian doesn't have any will to work closely with us. > He's not replying to us so far, so I agree with you. And I don't > think what Alex is suggesting to us is not so far from what we have > been discussing. He didn't say it should be outside of the ASF. ;) To be honest, I'm not really sure what the intent here is. For the past 5 years or so, there really hasn't been much need for much evolution or fast response from dnsjava - there haven't been many features that I've wanted to add, and there haven't been too many external patches. The dnsjnio patch set is, as far as I know, the only code that should be part of dnsjava but isn't. That's mostly my fault - I haven't had much time to work on dnsjava recently, and evaluating and working with a large patch takes more time than I've had. The intent here is about build a community around DNS protocol implementation. I agree with you that dnsjava is a very mature and stable product. But there are also demand for asynchronous DNS implementation. dnsjnio is a good example, and some people want to switch dnsjava's internal implementation with existing NIO framework to fully utilize asynchronous API. These changes will need quite a lot of work and we thought dnsjava and dnsjnio are a great starting point. I'm not sure you have interest in these changes, but there are about four guys who are interested in these changes, so we might be able to create a nice community around it. We also thought starting this work in the ASF will be beneficial to many parties such as James, MINA, and Directory project because they want to work closely with the DNS protocol implementor in the near future (or right now). Is your question about our intent clarified? WDYT? >> What about the "frequently updated dnsjava" you talk about? Who will do >> that? In what environment? What community? As it has been proposed to be >> BSD then it cannot be hosted by ASF because the Apache Foundation will >> only create/maintain ASLv2 projects (and will also need copyrights for >> everything maintained). >> >> Indeed, I really would like to know whether Brian has objections to such >> an effort, what would be his own preferences about dependencies (or >> evolutions) of his code, if he would be interested in collaborating in a >> more "community oriented" project, if he would be interested in an >> oversight role. If someone wants to fork dnsjava, I can't stop them. A "community oriented" project sounds like a good idea, but as I said above, there really hasn't been much call for new features. In the 8 years or so since the first dnsjava release, there's only been 1 serious request for commit access to the repository, which makes me wonder where the community is. People occasionally pop up and ask for large features (some of which make sense), but very infrequently contribute any code. If the decision was made to fork or evolve the code, I wouldn't object, but I don't know how much of a role I'd be willing to play. I'm not using dnsjava in any other large projects, so the only real development I do (other than applying patches) is adding small features needed for miscellaneous DNS testing and adding new record types. The main reason I use dnsjava for testing is that I know the API pretty well, and it's easy for me to write code using it - if the API evolved to the point that wasn't as familiar with it and my code didn't work, I'd probably continue to use the old version or use something else (like dnspython - dnsjava and small programs using it are the only java code I write anymore). Our primary goal is not about forking dnsjava. I think it's our last resort. Especially, I appreciate your effort to maintain dnsjava project as a previous user and a fan. With a bigger community, we could cope better with such a big request because it's not only you but all committers will have more chance to consider about t
Re: DNS Protocol (Was: DHCP Protocol Home)
On 6/20/07, Brian Wellington <[EMAIL PROTECTED]> wrote: > The intent here is about build a community around DNS protocol > implementation. I agree with you that dnsjava is a very mature and > stable product. But there are also demand for asynchronous DNS > implementation. dnsjnio is a good example, and some people want to > switch dnsjava's internal implementation with existing NIO framework > to fully utilize asynchronous API. These changes will need quite a > lot of work and we thought dnsjava and dnsjnio are a great starting > point. I'm not sure you have interest in these changes, but there are > about four guys who are interested in these changes, so we might be > able to create a nice community around it. We also thought starting > this work in the ASF will be beneficial to many parties such as James, > MINA, and Directory project because they want to work closely with the > DNS protocol implementor in the near future (or right now). Is your > question about our intent clarified? WDYT? If there are enough people to form a community, then it sounds like a good idea. > Our primary goal is not about forking dnsjava. I think it's our last > resort. Especially, I appreciate your effort to maintain dnsjava > project as a previous user and a fan. With a bigger community, we > could cope better with such a big request because it's not only you > but all committers will have more chance to consider about the worth > of the request. Definitely. If there are people interested in working on DNS code, I'm happy to let them. The fact that I've written almost all of dnsjava is more a reflection of the lack of contributed code than anything else. I am very glad that you are interested in collaboration with the interested developers. WDYT, other people? Does this sound good enough? To get the collaboration started, we could start from the incubation proposal if there's no objection. Stefano, I think you are most suitable person for writing the proposal in cooperation with Brian IMHO. :) I'm not offended by this; I was trying to explain more than anything else. I know that dnsjava's been mostly inactive for a while now, which is a combination of my lack of time and the fact that there haven't been many things to add. Thank you for your understanding! Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DNS Protocol (Was: DHCP Protocol Home)
On 6/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: "Trustin Lee" <[EMAIL PROTECTED]> wrote on 20/06/2007 09:32:44: > > > Our primary goal is not about forking dnsjava. I think it's our last > > > resort. Especially, I appreciate your effort to maintain dnsjava > > > project as a previous user and a fan. With a bigger community, we > > > could cope better with such a big request because it's not only you > > > but all committers will have more chance to consider about the worth > > > of the request. > > > > Definitely. If there are people interested in working on DNS code, I'm > > happy to let them. The fact that I've written almost all of dnsjava is > > more a reflection of the lack of contributed code than anything else. > > I am very glad that you are interested in collaboration with the > interested developers. WDYT, other people? Does this sound good > enough? To get the collaboration started, we could start from the > incubation proposal if there's no objection. Stefano, I think you are > most suitable person for writing the proposal in cooperation with > Brian IMHO. :) I'm not sure I understand. Is the proposal to extend and evolve dnsjava, or is the proposal to create an entirely new DNS project? Personally, I'd favour a community-driven evolution of dnsjava if this was an option. If I understood the general opinion in this thread, it was our first try to extend and evolve dnsjava. I guess everyone interested prefers community-driven evolution of dnsjava. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (INCUBATOR-53) Remove references to "escalation" from Incubation Policy
[ https://issues.apache.org/jira/browse/INCUBATOR-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473021 ] Trustin Lee commented on INCUBATOR-53: -- Looks very good to me. > Remove references to "escalation" from Incubation Policy > > > Key: INCUBATOR-53 > URL: https://issues.apache.org/jira/browse/INCUBATOR-53 > Project: Incubator > Issue Type: Improvement > Components: site >Reporter: Craig Russell > Assigned To: Craig Russell >Priority: Minor > Attachments: escalate.patch > > > Currently, incubation policy refers to "escalation", "migration", and > "graduation" when discussing graduation from the incubator to a TLP or a > sub-project. > This proposal standardizes on the terminology "graduation" to refer to this > process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Report reviews
Hi Jukka, FtpServer has graduated from the Incubator to be a subproject of MINA. Jukka Zitting wrote: > Hi, > > I reviewed the submitted project reports for April. I'm not sure if > people are actively following the page or the diffs, so here's a > summary of my review. > > OK: > > * CouchDB > * PDFBox (I'm a mentor) > * Tika (I'm a mentor) > > OK with comments: > > * CXF - Good luck for the TLP! > * Imperius - Issues before graduation? > * JSPWiki - Issues before graduation? > * Qpid - Did you understand the IPMC concerns about diversity? The > report seems to indicate otherwise. Also missing: Qpid is ...? > Incubating since? > * Sanselan - Issues before graduation? > * Shindig - Issues before graduation? > * UIMA - Too comfortable in the Incubator? Focus on growing the > community and on graduating! > > Report missing: > > * Buildr > * FtpServer > * Ivy > * RCF > * JuiCE > * Lucene.Net > > BR, > > Jukka Zitting > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: OpenPGP digital signature
