[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866530#action_12866530 ] Cliff Jansen commented on QPID-2589: Would it be possible to build the WCF (channel and service interfaces) on top of this API? Well, no. But that is the same answer for the old 0-10 client code and, nevertheless, the WCF channel uses that for 95% of its work and sneaks around it for some additional functionality. In the end, this new API is *much* less rich, which means the WCF channel may have to work much harder behind the scenes to get its work done. But that still may be the right balance. The API should be true to the target developer base first - how many need to be transaction resource managers or perftest stars? The major outages are dtx support and message body content optimizations (one time set, one time retrieve, i.e. the WCF paradigm, and I would argue a not uncommon scenario). Off the top of my head, I also worry about the limited async functionality. The current WCF implementation relies heavily on async related classes in the old API, such as Future and Completion. Their absence in this API is not fatal (just run another thread to block on a session.sync(true)), but reduces options for performance optimizations. The current WCF implementation is impressively speedy and it would be sad to handicap it. I would be most happy to see things evolve so that the messaging API becomes a libc-ish entity that can work in an application that simultaneously uses kernel-ish functionality for finer grained capabilities (without pulling the rug out from under libc). I am all for keeping the Advanced in AMQP. Add a .NET binding to QPID Messaging API Key: QPID-2589 URL: https://issues.apache.org/jira/browse/QPID-2589 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Chuck Rolke Assignee: Ted Ross Fix For: 0.7 Attachments: qpid_bindings.diff This binding package is a .NET Interop wrapper around the Qpid Messaging interface. It exposes the Messaging interface through a series of managed code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [.net]: some debate please
Perhaps it would be useful for somebody to assist this debate by introducing the messaging API in the .NET context and addressing why, for example, .NET programmers need this API, but Java programmers don't. Or why a developer who might be inclined to use WCF should use this messaging API instead. Looking at the initial code drop, I have a very hard time imagining a .NET programmer who might feel remotely comfortable using it. This is not a comment on the quality or functionality of the module, just on the utter disregard for basic .NET conventions of the C++ API as transposed to .NET, i.e. the surface area of the library. I don't think it would take a lot of work to address this. The question remains whether this new client intends to ignore distributed transactions, including the new promotable transactions in AMQP 1.0. But compared to the existing dotnet client, from a practical point of view, a module whose heavy lifting is largely done in the C++ space will automatically benefit from bug fixes to that code base. This beats the current dotnet mechanism of running a code translator against a Java snapshot every other year. Carl Trieloff wrote: The current WCF uses the 0-10 API, I would suggest moving the WCF client to the updated C++ API. I believe this has been agreed to be done at some point before on the list which would then be consistent with this work Actually the current WCF implementation uses the 0-10 C++ API where convenient and bypasses it when necessary. The complete lack of distributed transaction support in the updated C++ API means that even more behind the scenes work will be required. But wherever possible, the new messaging API would be used. Regardless of recent events, the Interop layer of the WCF channel was known to need rewriting for AMQP 1.0. I had hoped that the rewrite would lead to a 0-10 and 1.0 friendly library which, surprise, looks much like this messaging API plus qpid-config. But, realistically, that would happen after many of the other TODO items in the WCF Reame file were done. Cliff - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866533#action_12866533 ] Gordon Sim commented on QPID-2589: -- The major outages are dtx support and message body content optimizations (one time set, one time retrieve, i.e. the WCF paradigm, and I would argue a not uncommon scenario). These are certainly gaps we would want to address in the messaging API and its implementation. Off the top of my head, I also worry about the limited async functionality. The current WCF implementation relies heavily on async related classes in the old API, such as Future and Completion. I'd be keen to explore these worries in some more detail. Could we tackle one or two concrete cases to begin with? Add a .NET binding to QPID Messaging API Key: QPID-2589 URL: https://issues.apache.org/jira/browse/QPID-2589 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Chuck Rolke Assignee: Ted Ross Fix For: 0.7 Attachments: qpid_bindings.diff This binding package is a .NET Interop wrapper around the Qpid Messaging interface. It exposes the Messaging interface through a series of managed code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Want to Help - qpid newbie
Hi Josh, Thx for your reply. Iam not an expert with the SELinux API, I have looked at it before. I chose that because it sounded familiar and I thot it would be easy to start with. If you can suggest anything better for me, that will be great. Thanks Kanthi. -- View this message in context: http://apache-qpid-developers.2158895.n2.nabble.com/Want-to-Help-qpid-newbie-tp5036655p5039120.html Sent from the Apache Qpid developers mailing list archive at Nabble.com. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Want to Help - qpid newbie
Hi Josh, Thx for your reply. Iam not an expert with the SELinux API, I have looked at it before. I chose that because it sounded familiar and I thot it would be easy to start with. If you can suggest anything better for me, that will be great. Thanks Kanthi. -- View this message in context: http://apache-qpid-developers.2158895.n2.nabble.com/Want-to-Help-qpid-newbie-tp5036655p5039303.html Sent from the Apache Qpid developers mailing list archive at Nabble.com. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [.net]: some debate please
Gordon Sim wrote: On 05/10/2010 09:33 PM, tr...@apache.org wrote: Author: tross Date: Mon May 10 20:33:19 2010 New Revision: 942892 URL: http://svn.apache.org/viewvc?rev=942892view=rev Log: QPID-2589 - Applied patch from Chuck Rolke. This commit adds a new component and yet another approach for .net, specifically a .net wrapper around the c++ messaging API. We also have a wcf client (this also uses some c++ code, but uses the 0-10 specific API plus some direct use of the internals of the client), and two different pure c# clients for 0-8 and 0-10 respectively. Four different options each with its own codebase isn't sensible. We can't maintain them all and it is confusing for users. While aspects of this latest approach certainly appeal to me personally (the messaging API is better for a number of reasons than the older API and wrapping that also keeps the clients more aligned conceptually), I think it deserves a bit more debate. Specifically we have to explicitly decide as a community whether this new approach is a path we should pursue. I'm keen to hear the thoughts of Cliff, Aidan and other .net aficionados. While I prefer depending on the new C++ messaging API to depending on the old one, I don't think either one is really the correct choice. I think the WCF client should actually depend on a C# interface to the message API, thus giving something that is more reasonable to use directly from C#, while being able to be back-ended by either the C++ implementation of the messaging API or by a pure C# implementation if one is so inclined to write one. On purely procedural note, it is IMHO *very* bad form to drop such a patch into the repo without some list discussion prior. I'm particularly uncomfortable that this was committed by someone who (as far as I'm aware) is not a regular WCF committer, nor intends to become one. This has been the general approach in this area since the first dotnet effort ages ago. It's no wonder there are 4 completely different approaches half of which are rotting. Cleaning out the rot is only half the problem here, we *really* have to stop doing stuff like this or we'll keep on making more rot. IMHO this patch should be backed out until some discussion has happened and its clear that those responsible for maintaining WCF going forward are comfortable with the approach. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [.net]: some debate please
Cliff Jansen wrote: Perhaps it would be useful for somebody to assist this debate by introducing the messaging API in the .NET context and addressing why, for example, .NET programmers need this API, but Java programmers don't. Or why a developer who might be inclined to use WCF should use this messaging API instead. I think Java developers do need this as it addresses a number of use cases that are not possible with JMS, e.g. explicit control over sync vs async publish, unacked message windows, and prefetch, as well as better support for non-blocking programming models. It's just lower priority because JMS covers many of the common cases already. Also, it makes sense to build it out and let it mature a bit in C++/Python before trying to take it to other languages. Really this API isn't a million miles away from JMS anyways, so an ideal architecture would be JMS as a very thin layer on top of a Java version of the API. This would allow people to use JMS for many things they already know how to do there and then drop into the API for more advanced scenarios. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [.net]: some debate please
On 05/12/2010 11:21 AM, Cliff Jansen wrote: Perhaps it would be useful for somebody to assist this debate by introducing the messaging API in the .NET context and addressing why, for example, .NET programmers need this API, but Java programmers don't. Or why a developer who might be inclined to use WCF should use this messaging API instead. Looking at the initial code drop, I have a very hard time imagining a .NET programmer who might feel remotely comfortable using it. This is not a comment on the quality or functionality of the module, just on the utter disregard for basic .NET conventions of the C++ API as transposed to .NET, i.e. the surface area of the library. I don't think it would take a lot of work to address this. I think a natural .NET interface is essential ans I expect on that point we will all agree. Whether there would be any interest in using an API like that available in c++/python directly instead of just using WCF is an important question. I don't have an answer for that at present. The question remains whether this new client intends to ignore distributed transactions, including the new promotable transactions in AMQP 1.0. We certainly do want the c++ messaging API to be extended to allow distributed transaction support to be added. (I'd also be keen on exploring any optimisations on handling body content). But compared to the existing dotnet client, from a practical point of view, a module whose heavy lifting is largely done in the C++ space will automatically benefit from bug fixes to that code base. This beats the current dotnet mechanism of running a code translator against a Java snapshot every other year. I think the approach to implementing whatever interface(s) is(are) exposed to .NET users is also important to us as a community. Re-using another implementation to reduce the amount of specific code clearly has the potential to reduce the maintenance burden. It may of course have some downsides as well. The key I think is to discuss these points openly and try to reach some agreement on approach. We need to co-ordinate our efforts and we can only do so by sharing our ideas. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2601) cmake configure step broken Tues night 11-April
cmake configure step broken Tues night 11-April --- Key: QPID-2601 URL: https://issues.apache.org/jira/browse/QPID-2601 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.7 Environment: Windows cmake Reporter: Steve Huston CMake Error in src/CMakeLists.txt: Cannot find source file Session_0_10.h. Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [.net]: some debate please
Gordon Sim wrote: On 05/12/2010 11:21 AM, Cliff Jansen wrote: Perhaps it would be useful for somebody to assist this debate by introducing the messaging API in the .NET context and addressing why, for example, .NET programmers need this API, but Java programmers don't. Or why a developer who might be inclined to use WCF should use this messaging API instead. Looking at the initial code drop, I have a very hard time imagining a .NET programmer who might feel remotely comfortable using it. This is not a comment on the quality or functionality of the module, just on the utter disregard for basic .NET conventions of the C++ API as transposed to .NET, i.e. the surface area of the library. I don't think it would take a lot of work to address this. I think a natural .NET interface is essential ans I expect on that point we will all agree. Whether there would be any interest in using an API like that available in c++/python directly instead of just using WCF is an important question. I don't have an answer for that at present. Even if there isn't interest in using this API directly, I think there is huge benefit to having all the clients share a common architecture as much as possible. Since the purpose of the messaging API is really to expose all the features of AMQP while abstracting away the protocol details and not imposing a particular programming model on the application (e.g. not requiring applications to dedicate threads to handle blocking calls), it makes sense to me that each client would have a layer that corresponds to this even if it is not necessarily exposed directly. Obviously this particularly makes sense for languages that can directly use C/C++ code via swig or other means (which is actually pretty much any language). --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [.net]: some debate please
On 05/12/2010 12:50 PM, Rafael Schloming wrote: Even if there isn't interest in using this API directly, I think there is huge benefit to having all the clients share a common architecture as much as possible. Since the purpose of the messaging API is really to expose all the features of AMQP while abstracting away the protocol details and not imposing a particular programming model on the application (e.g. not requiring applications to dedicate threads to handle blocking calls), it makes sense to me that each client would have a layer that corresponds to this even if it is not necessarily exposed directly. I agree 100%! - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2600) ACL policy doesn't permit certain characters in usernames added to groups
[ https://issues.apache.org/jira/browse/QPID-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866556#action_12866556 ] Andrew Kennedy commented on QPID-2600: -- I have also based the Java group entity parsing on the C++ parser and the website documentation. Should this be changed, with the @ and / swapped, to: name [ /domain [ @realm ] ] ACL policy doesn't permit certain characters in usernames added to groups - Key: QPID-2600 URL: https://issues.apache.org/jira/browse/QPID-2600 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.7 Description of problem: Unable to add a host principle to a group, the acl policy file fails to load and prevents qpidd from running. I guess this is partly due to us not figuring out what is exactly allowed for group and usernames. How reproducible: Fails every time. Steps to Reproduce: 1. Add a host or service principle to a group in the acl file. Something like this will suffice: group somegroup host/somemachine.example@example.com Actual results: Failure to start. Error message is: Daemon startup failed: Could not read ACL file ACL format error: /etc/qpid/policy.acl:25: Name host/somemachine.example@example.com contains illegal characters. Expected results: Should load and parse the group cleanly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2541) Separate Group an ACL configuration and make group sources pluggable
[ https://issues.apache.org/jira/browse/QPID-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866562#action_12866562 ] Andrew Kennedy commented on QPID-2541: -- Understood, and this is what I would like - If we are going to use LDAP, it would be for both authentication and group membership. Having groups defined and included in only the ACL file parser was what I was wanting to change. This could easily fit in with the existing authentication mechanisms, and that is probably the best place for it, yes. The notion of separate user and group mechanisms was meant to describe the current situation, and obviously it makes no sense to have a group file delivering the groups when authentication is done via active directory, say. I believe there is a need for this when external authentication mechanisms are used for precisely the reason above - it is a possible security issue! The external group file mechanism is meant to work in combination with the current external password file, decoupling groups from ACLs. Hope that explains things better, Andrew. Separate Group an ACL configuration and make group sources pluggable Key: QPID-2541 URL: https://issues.apache.org/jira/browse/QPID-2541 Project: Qpid Issue Type: Sub-task Components: Java Broker Reporter: Andrew Kennedy Fix For: 0.7 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2541) Separate Group an ACL configuration and make group sources pluggable
[ https://issues.apache.org/jira/browse/QPID-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866573#action_12866573 ] Rajith Attapattu commented on QPID-2541: Thanks for the explanation. As long as the group mechanism is tied to the authentication I am fine with it. I would also like to retain the ability to specify groups in the ACL file as well. Separate Group an ACL configuration and make group sources pluggable Key: QPID-2541 URL: https://issues.apache.org/jira/browse/QPID-2541 Project: Qpid Issue Type: Sub-task Components: Java Broker Reporter: Andrew Kennedy Fix For: 0.7 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2600) ACL policy doesn't permit certain characters in usernames added to groups
[ https://issues.apache.org/jira/browse/QPID-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866580#action_12866580 ] Rajith Attapattu commented on QPID-2600: Thx good catch ! user = userna...@domain[/realm]] should be changed to user = name [ /domain [ @realm ] ] However currently the c++ broker doesn't treat the '@' as optional as we do have the concept of a domain. I know the Java broker doesn't, as it doesn't support GSSAPI etc.. I could probably default to the default-broker-realm if nothing is specified, rather than flag it as an error. The website documentation needs a bit of work for sure :) We are moving the ACL documentation from the wiki to the new doc book format kept in svn. So going forward we can keep them in sync a bit more easily. ACL policy doesn't permit certain characters in usernames added to groups - Key: QPID-2600 URL: https://issues.apache.org/jira/browse/QPID-2600 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.7 Description of problem: Unable to add a host principle to a group, the acl policy file fails to load and prevents qpidd from running. I guess this is partly due to us not figuring out what is exactly allowed for group and usernames. How reproducible: Fails every time. Steps to Reproduce: 1. Add a host or service principle to a group in the acl file. Something like this will suffice: group somegroup host/somemachine.example@example.com Actual results: Failure to start. Error message is: Daemon startup failed: Could not read ACL file ACL format error: /etc/qpid/policy.acl:25: Name host/somemachine.example@example.com contains illegal characters. Expected results: Should load and parse the group cleanly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2600) ACL policy doesn't permit certain characters in usernames added to groups
[ https://issues.apache.org/jira/browse/QPID-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866586#action_12866586 ] Rajith Attapattu commented on QPID-2600: However currently the c++ broker doesn't treat the '@' as optional as we do have the concept of a domain. should be changed as However currently the c++ broker doesn't treat the '@' as optional as we do have the concept of a realm. ACL policy doesn't permit certain characters in usernames added to groups - Key: QPID-2600 URL: https://issues.apache.org/jira/browse/QPID-2600 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.7 Description of problem: Unable to add a host principle to a group, the acl policy file fails to load and prevents qpidd from running. I guess this is partly due to us not figuring out what is exactly allowed for group and usernames. How reproducible: Fails every time. Steps to Reproduce: 1. Add a host or service principle to a group in the acl file. Something like this will suffice: group somegroup host/somemachine.example@example.com Actual results: Failure to start. Error message is: Daemon startup failed: Could not read ACL file ACL format error: /etc/qpid/policy.acl:25: Name host/somemachine.example@example.com contains illegal characters. Expected results: Should load and parse the group cleanly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Website prototype take2
On 05/10/2010 10:21 AM, Rajith Attapattu wrote: I am hoping to do as many static pages as I can during the weekend. However I'd appreciate if people can volunteer to help with some of the static pages. The first step might be to take inventory of what gets handled as static HTML. I hope that will be relatively few pages, and that it will not include the documentation pages. I assume that the pages already converted to Docbook in the doc/book/src directory will be managed using DocBook, converted automatically to PDF. We can also convert them to HTML in various ways. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Want to Help - qpid newbie
Thx for your reply. Iam not an expert with the SELinux API, I have looked at it before. I chose that because it sounded familiar and I thot it would be easy to start with. If you can suggest anything better for I'm actually looking at this again - the trick is understanding userspace object managers, because there isn't a concise, easy to understand for SELinux newbies example available. Debugging the policy itself as it relates to OS-level objects (files, sockets, directories, etc.) is not as difficult. I think I've come up with a good example of a userspace object manager - something that uses SELinux to apply security models to objects that exist in a program itself. I'm going to work on this for a couple of days and perhaps we can touch base then if you haven't found something else that tickles your fancy. Cheers, -JK -- - http://www.globalherald.net/jb01 GlobalHerald.NET, the Smarter Social Network! (tm) - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Website prototype take2
On Wed, May 12, 2010 at 10:43 AM, Jonathan Robie jonathan.ro...@redhat.com wrote: On 05/10/2010 10:21 AM, Rajith Attapattu wrote: I am hoping to do as many static pages as I can during the weekend. However I'd appreciate if people can volunteer to help with some of the static pages. The first step might be to take inventory of what gets handled as static HTML. I hope that will be relatively few pages, and that it will not include the documentation pages. I would assume the static pages would be 1. Home 2. Mailing lists 3. Source repositories 4. Qpid Integrated with.. 5. People 6. Acknowledgements 7. What is AMQP ? 8. Getting Involved The following should be direct links 1. License 2. Issue Reporting 3. Wiki 4. ASF I'd prefer the rest to be maintained in svn and export generated HTML. In particular there is a lot of benefit in maintaining the following in svn to ensure they are all current at any given time. 1. Download 2. FAQ 3. Getting Started 4. Building Qpid I am not sure what to do about developer pages. I assume that the pages already converted to Docbook in the doc/book/src directory will be managed using DocBook, converted automatically to PDF. We can also convert them to HTML in various ways. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Website prototype take2
On 05/12/2010 10:53 AM, Rajith Attapattu wrote: On Wed, May 12, 2010 at 10:43 AM, Jonathan Robie jonathan.ro...@redhat.com wrote: The first step might be to take inventory of what gets handled as static HTML. I hope that will be relatively few pages, and that it will not include the documentation pages. I would assume the static pages would be 1. Home 2. Mailing lists 3. Source repositories 4. Qpid Integrated with.. 5. People 6. Acknowledgements 7. What is AMQP ? 8. Getting Involved The following should be direct links 1. License 2. Issue Reporting 3. Wiki 4. ASF I agree with all of this. I'd prefer the rest to be maintained in svn and export generated HTML. In particular there is a lot of benefit in maintaining the following in svn to ensure they are all current at any given time. 1. Download 2. FAQ 3. Getting Started 4. Building Qpid Yes, that makes sense. I am not sure what to do about developer pages. Me neither. Initially, I suggest we simply refer to the existing Wiki pages. But I think we need to figure out what we really want the developer pages to include, and what we want them to accomplish, before redesigning that part. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Closed: (QPID-2601) cmake configure step broken Tues night 11-April
[ https://issues.apache.org/jira/browse/QPID-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston closed QPID-2601. -- Assignee: Steve Huston Resolution: Cannot Reproduce Problem was apparently the result of left-over cruft from a previous build. cmake configure step broken Tues night 11-April --- Key: QPID-2601 URL: https://issues.apache.org/jira/browse/QPID-2601 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.7 Environment: Windows cmake Reporter: Steve Huston Assignee: Steve Huston CMake Error in src/CMakeLists.txt: Cannot find source file Session_0_10.h. Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
