Non-XA compliant resource participation in distributed transactions
by John P. A. Verhaeg
Seems like we ought to strive to support n-1 XA resources for
distributed transactions, allowing for the last participant in a
transaction (thus, this participants updates can't be done in parallel
with the other resources) to not support XA transactions, but still
participate in a distributed transaction with other XA-compliant
resources. Unlike compensating transactions, the non-XA participant
would appear transactional and none of the updates would be visible
until the entire transaction was complete. It seems like this could
open up many more possible configurations for customers.
17 years, 7 months
- 4
- 16
chat about next steps of the project
by Stefano Maestri
Hi folks,
Randall and me had an interesting chat on irc about next steps of the
project and my possible contributions.
In agreement with Randall I put here (hoping attachment is permitted on
this ML) the transcript of our chat.
For convenient reading I made also available it online on my blog:
http://www.javalinux.it/wordpress/?p=31
have fun.
--
bye
Stefano
www.javalinux.it www.wibo.it
<span style="color: red;">rhauch: I'll get the graph API into SVN soon.</span>
<span style="color: red;">rhauch: Is there an area you want to work?</span>
<span style="color: red;">rhauch: Other sequencers? Federation?</span>
<span style="color: blue;">maeste: Federation would be fun</span>
<span style="color: blue;">maeste: and I'm thinking about sequencers useful for ESB/Overlord</span>
<span style="color: red;">rhauch: any experience with JBoss Cache?</span>
<span style="color: blue;">maeste: in particulòar I'm looking at ESB code which write on JCR messages</span>
<span style="color: blue;">maeste: just a little. Just ine project, not big</span>
<span style="color: blue;">maeste: but I have an idea about it, not completely ignorant</span>
<span style="color: blue;">maeste: concluding about ESB messages, I think a sequencer on it can be very useful, in particular if used togheter an UDDI sequencer</span>
<span style="color: blue;">maeste: but as said Federation and connectors would be big fun for me</span>
<span style="color: red;">rhauch: i'm not sure i understand what would be sequenced</span>
<span style="color: blue;">maeste: ESB track messages exchanged</span>
<span style="color: blue;">maeste: and would be good to sequence message header</span>
<span style="color: blue;">maeste: containing EPRs</span>
<span style="color: blue;">maeste: of request and response</span>
<span style="color: red;">rhauch: those headers would be stored in JCR?</span>
<span style="color: blue;">maeste: I think so. Am I wrong?</span>
<span style="color: red;">rhauch: oh, well they certainly could be stored in JCR.</span>
<span style="color: red;">rhauch: I just didn't know how ESB would use JCR for that.</span>
<span style="color: blue;">maeste: I think it would be used to query jcr to understand how many times messages pass on EPRs</span>
<span style="color: red;">rhauch: EPR = ?</span>
<span style="color: blue;">maeste: and eventually we can sequence the route of message</span>
<span style="color: blue;">maeste: EndPoint......I can't recall the 'R'</span>
<span style="color: blue;">maeste: a moment...</span>
<span style="color: red;">rhauch: router?</span>
<span style="color: blue;">maeste: no, it's the ws-addressing EPR, the unique uidentifier of source/destination of a message</span>
<span style="color: red;">rhauch: ah.</span>
<span style="color: blue;">maeste: R=Reference</span>
<span style="color: red;">rhauch: would it be useful to have a connector that publishes the message headers?</span>
<span style="color: blue;">maeste: well ESB already have a JCR repository</span>
<span style="color: red;">rhauch: I guess I'm wondering how long those need to be stored? forever would mean a lot of data, right?</span>
<span style="color: blue;">maeste: Yep</span>
<span style="color: blue;">maeste: it's the reason because ESB leave to the user the decision on how store on the repository</span>
<span style="color: blue;">maeste: there is an action</span>
<span style="color: blue;">maeste: that register a message on the repository</span>
<span style="color: blue;">maeste: just body and attributes at the moment</span>
<span style="color: blue;">maeste: not header</span>
<span style="color: blue;">maeste: but also body (and mainly body) may be a lot of data</span>
<span style="color: red;">rhauch: would you rather I create JIRA tasks, and you assign them to yourself?</span>
<span style="color: red;">rhauch: or would you rather discuss what needs to be done and then you create the tasks for what you'd work on?</span>
<span style="color: blue;">maeste: well it's better to have a little discussion before</span>
<span style="color: red;">rhauch: where did you want to start, maeste?</span>
<span style="color: blue;">maeste: well we can start from the roadmap</span>
<span style="color: blue;">maeste: IOW what you have in mind for next release?</span>
<span style="color: red;">rhauch: Two areas: more sequencers and federation (at least read, probably not write)</span>
<span style="color: blue;">maeste: oki</span>
<span style="color: blue;">maeste: about sequencers i'd like to write some SOA related</span>
<span style="color: red;">rhauch: okay, that'd be great.</span>
<span style="color: blue;">maeste: WSDLs, ESB Message....maybe UDDI</span>
<span style="color: red;">rhauch: johnny verhaeg works with me in STL, and he'll be looking into a MetaMatrix sequencer (and maybe XSD)</span>
<span style="color: blue;">maeste: I don't think policy one yet, because we (in overlord) have to discuss about what's kind of policy want to support</span>
<span style="color: red;">rhauch: Someone else on the discussion forums started on a Java sequencer, too. Not sure where he is.</span>
<span style="color: red;">rhauch: (where he is with the sequencer; I think he's in germany)</span>
<span style="color: red;">rhauch: John is also looking into the view service, but really just some rough prototyping and investigation of some technologies.</span>
<span style="color: red;">rhauch: He won't be spending too much time on that, tho.</span>
<span style="color: blue;">maeste: about java seq...code or class?</span>
<span style="color: red;">rhauch: I believe source, although I'd love to have a bytecode sequencer!</span>
<span style="color: blue;">maeste: about view service...another interesting area</span>
<span style="color: red;">rhauch: Both should really generate the same output structure.</span>
<span style="color: blue;">maeste: I'd like to give my thought when it will be time</span>
<span style="color: blue;">maeste: since I think some of these view could be used on overlord</span>
<span style="color: red;">rhauch: very cool.</span>
<span style="color: red;">rhauch: Oh, absolutely.</span>
<span style="color: red;">rhauch: I anticipate views for all kinds of data</span>
<span style="color: blue;">maeste: and also because I'm used to works with web applications</span>
<span style="color: blue;">maeste: already some technology in mind?</span>
<span style="color: blue;">maeste: I suppose seam</span>
<span style="color: red;">rhauch: yes, seam</span>
<span style="color: blue;">maeste: and....GWT? or JavaFX?</span>
<span style="color: red;">rhauch: not sure about view technology: jsf or Flex</span>
<span style="color: blue;">maeste: ah...the two I not mentioned...;)</span>
<span style="color: red;">rhauch: well, GWT and JavaFX are options too.</span>
<span style="color: blue;">maeste: Flex is indeed good technology too</span>
<span style="color: red;">rhauch: I'm concerned about the ability in GWT to dynamically generate views.</span>
<span style="color: blue;">maeste: I have some more doubt about jsf</span>
<span style="color: blue;">maeste: and I speak as leader of some big jsf projects</span>
<span style="color: red;">rhauch: We already tried that, and it worked, but it was a little painful.</span>
<span style="color: red;">rhauch: great feedback, then.</span>
<span style="color: red;">rhauch: i've never been a big fan of jsf.</span>
<span style="color: blue;">maeste: yep right about dynamic generation of GWT</span>
<span style="color: red;">rhauch: i don't know much about JavaFX</span>
<span style="color: red;">rhauch: Flex has an interesting XML-based view definition.</span>
<span style="color: blue;">maeste: I'm studying it right now</span>
<span style="color: red;">rhauch: Hmm... data-driving views.</span>
<span style="color: blue;">maeste: it looks very very promising</span>
<span style="color: blue;">maeste: Yep I know about this Flex feature...I think something like that could be managed in JAvaFX, with a reflection like approach</span>
<span style="color: red;">rhauch: i need to read up on JavaFX</span>
<span style="color: blue;">maeste: anyway it's another story...we can discuss about views in next future on ML</span>
<span style="color: red;">rhauch: well, I'll have to introduce you to John, maybe on the dna-dev@ list.</span>
<span style="color: blue;">maeste: I need to understand better which kind of dynamic generation you have in mind</span>
<span style="color: blue;">maeste: to give my thought</span>
<span style="color: red;">rhauch: well, think about this</span>
<span style="color: red;">rhauch: ...</span>
<span style="color: red;">rhauch: in JCR there's a structure representing a Java class</span>
<span style="color: red;">rhauch: so a node type for the class, with child nodes for the different members.</span>
<span style="color: red;">rhauch: and all these nodes have their own properties.</span>
<span style="color: red;">rhauch: The whole point of the view system is to build a domain-specific view using a subgraph.</span>
<span style="color: red;">rhauch: So the "Java class" view would know it needs to get the properties on the class node AND get the member child nodes and their properties.</span>
<span style="color: red;">rhauch: The resulting "message" (wrong term, really) would contain all the information necessary to build a view using a specific UI technology.</span>
<span style="color: red;">rhauch: The big thing is when navigating the repository</span>
<span style="color: red;">rhauch: and you come across a node that matches the Java class, that the "Java class" view is selected and used to generate the view.</span>
<span style="color: blue;">maeste: ok, so I have to see in views a class as a class and not as row xml</span>
<span style="color: blue;">maeste: and wsdls as wsdls and so on</span>
<span style="color: blue;">maeste: great</span>
<span style="color: red;">rhauch: Right, and not a node with properties and links to child nodes.</span>
<span style="color: red;">rhauch: exactly</span>
<span style="color: red;">rhauch: Ideally, the views could be composed</span>
<span style="color: blue;">maeste: of course</span>
<span style="color: red;">rhauch: so that if a node "looks like" a Java class AND a WSDL, then a single view would include both facets.</span>
<span style="color: blue;">maeste: well it's not a joke...doesn't matter what technology we will choose...it still to don't be a joke!</span>
<span style="color: red;">rhauch: But in the end, the user should understand what they're looking at, because it's expressed in their terms and in ways they understand.</span>
<span style="color: blue;">maeste: ok, a grreat idea indeed</span>
<span style="color: red;">rhauch: Oh, and we should have views that show the views.</span>
<span style="color: red;">rhauch: :-)</span>
<span style="color: red;">rhauch: Basically, we want to manage and configure DNA using DNA.</span>
<span style="color: blue;">maeste: I can't immagine an application implemented in jsf like this one which stay under control... jsf tend to don't scale when you have an abstract approach</span>
<span style="color: red;">rhauch: Now can you see why I like the FLEX approach?</span>
<span style="color: blue;">maeste: the easiest and natural way would be XML+XSL or XML driven Flex indeed...but let me investigate a little more about JAvaFX</span>
<span style="color: red;">rhauch: architecturally, it fits very nicely.</span>
<span style="color: red;">rhauch: that'd be great. again, I'll introduce you to John over email.</span>
<span style="color: blue;">maeste: oki</span>
<span style="color: red;">rhauch: so we talked about view system</span>
<span style="color: red;">rhauch: and a bit about sequencers.</span>
<span style="color: blue;">maeste: coming back to Federation...</span>
<span style="color: blue;">maeste: (BTW view system isn't expected for next release, right?)</span>
<span style="color: red;">rhauch: no, views is not this next release.</span>
<span style="color: red;">rhauch: again, just investigating an approach so we know how to plan and how it might fit with anything we're doing now.</span>
<span style="color: blue;">maeste: yep of course...and it's fun</span>
<span style="color: red;">rhauch: we talked a bit about federation a week or so ago</span>
<span style="color: red;">rhauch: and there's some detail in the Getting Started doc.</span>
<span style="color: blue;">maeste: yep I read and I recall our chat</span>
<span style="color: red;">rhauch: so any questions? areas that were vague?</span>
<span style="color: blue;">maeste: the general idea is clear</span>
<span style="color: blue;">maeste: my question is about</span>
<span style="color: blue;">maeste: how do you think to tier this component</span>
<span style="color: blue;">maeste: where stay cache</span>
<span style="color: blue;">maeste: where the tree api</span>
<span style="color: blue;">maeste: and so on</span>
<span style="color: red;">rhauch: ok</span>
<span style="color: blue;">maeste: and another one</span>
<span style="color: blue;">maeste: is </span>
<span style="color: blue;">maeste: what do you think as container for DNA</span>
<span style="color: blue;">maeste: JBoss Microcontainer?</span>
<span style="color: red;">rhauch: yes on MC</span>
<span style="color: blue;">maeste: A standalone server or a deployable app?</span>
<span style="color: red;">rhauch: hmm...</span>
<span style="color: blue;">maeste: And what about configuartion system?</span>
<span style="color: blue;">maeste: And management system (MBean?)</span>
<span style="color: red;">rhauch: Ideally (from a user's view) a standalone server, but that's more work.</span>
<span style="color: blue;">maeste: sure about that?</span>
<span style="color: blue;">maeste: A deployable application is easier to understand</span>
<span style="color: blue;">maeste: and easier to go live in user's server farms</span>
<span style="color: red;">rhauch: well, easier for a developer. a bit more difficult from admins perspective.</span>
<span style="color: red;">rhauch: good points.</span>
<span style="color: blue;">maeste: Not totally agree</span>
<span style="color: blue;">maeste: I know some big farms with a lot of JBoss instance</span>
<span style="color: red;">rhauch: I'm still not convinced.</span>
<span style="color: blue;">maeste: and for example some admins</span>
<span style="color: blue;">maeste: prefers ESB as deployable </span>
<span style="color: blue;">maeste: than standalone server</span>
<span style="color: blue;">maeste: because JBossAS is already known by them</span>
<span style="color: red;">rhauch: no doubt. people have different preferences.</span>
<span style="color: red;">rhauch: I came from the MetaMatrix group</span>
<span style="color: blue;">maeste: Anyway ideal approach</span>
<span style="color: red;">rhauch: and MetaMatrix is really like a database.</span>
<span style="color: blue;">maeste: would be both</span>
<span style="color: red;">rhauch: and deploying a "database-like thing" into an app server really confused people.</span>
<span style="color: blue;">maeste: as ESB group did for their product</span>
<span style="color: red;">rhauch: yes, ideal would be both.</span>
<span style="color: blue;">maeste: yep u are right on this point</span>
<span style="color: red;">rhauch: in fact, the deployable would really be just a bundled JBoss server, right?</span>
<span style="color: blue;">maeste: right</span>
<span style="color: blue;">maeste: it's just matter of packaging and let me say marketing ;)</span>
<span style="color: red;">rhauch: sorry, I mean to say "stand alone server would really be just a deployable and a JBoss server"</span>
<span style="color: blue;">maeste: I understood</span>
<span style="color: red;">rhauch: Right, and productization. (with my JBoss hat on)</span>
<span style="color: blue;">maeste: LOL</span>
<span style="color: red;">rhauch: I think for the near term, we'll actually be used inside other apps/projects/products.</span>
<span style="color: blue;">maeste: or better with your RED HAT on ;)</span>
<span style="color: red;">rhauch: my red fedora</span>
<span style="color: blue;">maeste: lol</span>
<span style="color: red;">rhauch: we all have them, ya know</span>
<span style="color: blue;">maeste: oki, so we start with deployable one..</span>
<span style="color: blue;">maeste: my other questions:</span>
<span style="color: blue;">maeste: config and management system</span>
<span style="color: red;">rhauch: oh yeah.</span>
<span style="color: blue;">maeste: (not really coupled only with federation)</span>
<span style="color: red;">rhauch: and monitoring.</span>
<span style="color: blue;">maeste: Let me say 0.1 is more an API than a server</span>
<span style="color: blue;">maeste: I think next releases have to be PRODUCTIZED</span>
<span style="color: blue;">maeste: ;)</span>
<span style="color: blue;">maeste: adding these features</span>
<span style="color: red;">rhauch: I think the best approach is to support MBeans, to allow for tools like JBoss ON to monitor and control the "system"</span>
<span style="color: blue;">maeste: yes of course</span>
<span style="color: red;">rhauch: (although that's strictly required for JBoss ON)</span>
<span style="color: red;">rhauch: I think there are two ways we can proceed with config/mgmt/monitoring</span>
<span style="color: red;">rhauch: One is the "traditional" way, with MBeans, Microcontainer config, and such.</span>
<span style="color: red;">rhauch: Another is to use the repository.</span>
<span style="color: blue;">maeste: hmmm....I'm not sure to understand</span>
<span style="color: red;">rhauch: Let the repository define the configuration, and be the place we store monitoring results.</span>
<span style="color: red;">rhauch: To change the configuration, change the data in the "/dna:system" branch of the repository, and the system responds.</span>
<span style="color: red;">rhauch: For example, to configure a sequencer, add (or change) the data in "/dna:system/dna:sequencers/MySequencer"</span>
<span style="color: blue;">maeste: The question here is....would the user be happy to have to learn a new approach?</span>
<span style="color: red;">rhauch: well, that's where we'd have to adapt it to what they're familiar with.</span>
<span style="color: blue;">maeste: One more time the ideal approach is to use both and "gateway" the two</span>
<span style="color: red;">rhauch: Yes. Federation, anyone?</span>
<span style="color: red;">rhauch: :-)</span>
<span style="color: blue;">maeste: gotcha</span>
<span style="color: red;">rhauch: Seriously. I think that some of the "/dna:system" repository data could actually be federated from microcontainer config or from MBeans.</span>
<span style="color: blue;">maeste: Federation read/write traditional config</span>
<span style="color: red;">rhauch: Yup.</span>
<span style="color: blue;">maeste: And here we get back to views to admin DNA</span>
<span style="color: red;">rhauch: Exactly!</span>
<span style="color: blue;">maeste: Great...I'm really impressed</span>
<span style="color: red;">rhauch: It's just taking the "data-centric" approach to an extreme, I think. :-)</span>
<span style="color: blue;">maeste: And a lot of ideas crowd my mind about what we can do with this approach also for soa governance</span>
<span style="color: red;">rhauch: And, it's possible that the projects like the Microcontainer could use DNA for managing their configuration.</span>
<span style="color: red;">rhauch: (once we advance enough)</span>
<span style="color: blue;">maeste: yep</span>
<span style="color: red;">rhauch: I don't want to push them this way, but if they see the benefits ...</span>
<span style="color: red;">rhauch: like versioning of a configuration</span>
<span style="color: blue;">maeste: I see the benefits for soa governance world for sure</span>
<span style="color: blue;">maeste: and also for microcontainer </span>
<span style="color: red;">rhauch: Right now, I think we can basically use DI and IOC in our design</span>
<span style="color: red;">rhauch: and not have to pick a path.</span>
<span style="color: blue;">maeste: yep </span>
<span style="color: red;">rhauch: I think we will want to use the Microcontainer inside the "DNA Service"</span>
<span style="color: blue;">maeste: of course</span>
<span style="color: red;">rhauch: The MC is extensible enough that I think we can integrate the repository below it (sort of via a bootstrapping repository)</span>
<span style="color: red;">rhauch: in their configuration adapters.</span>
<span style="color: blue;">maeste: my first question was about tiering of federation....MC is the base and then...?</span>
<span style="color: red;">rhauch: well, i think all the services and components will be managed by the MC.</span>
<span style="color: red;">rhauch: (and wired together)</span>
<span style="color: blue;">maeste: (cool idea bootstrapping repository)</span>
<span style="color: red;">rhauch: I hope you could see that flavor in the example application code.</span>
<span style="color: red;">rhauch: I've been designing everything so that it can be configured in the MC.</span>
<span style="color: red;">rhauch: okay, so some of the other services/components.</span>
<span style="color: blue;">maeste: yep I see</span>
<span style="color: red;">rhauch: One, we'll have different connectors.</span>
<span style="color: red;">rhauch: the federation engine will delegate to the connectors to load a node,</span>
<span style="color: red;">rhauch: and the engine will merge the results for the same node from different connectors, placing all this in the cache</span>
<span style="color: red;">rhauch: Then, we'll have a graph API that allows working with the stuff in the cache.</span>
<span style="color: blue;">maeste: oki</span>
<span style="color: red;">rhauch: We can have a JCR implementation that uses this generic graph API.</span>
<span style="color: blue;">maeste: merging done by JBossCache right?</span>
<span style="color: red;">rhauch: or a UDDI implementation.</span>
<span style="color: red;">rhauch: Merging the node data from different connectors is probably not something JBoss Cache can do, because we really need to keep the different "node fragments" separate</span>
<span style="color: blue;">maeste: oki, JCR Implementation and UDDI implementation is better of course</span>
<span style="color: red;">rhauch: so we can manage them effectively.</span>
<span style="color: blue;">maeste: oki understood</span>
<span style="color: red;">rhauch: But we'll use JBoss Cache (should be pluggable, I think) to manage our cache of all the fragments.</span>
<span style="color: blue;">maeste: any palns of certify these implementations (JCR and UDDI)?</span>
<span style="color: red;">rhauch: Basically, the graph implementation would work with the different fragments and do the merging.</span>
<span style="color: red;">rhauch: Yes, we'll need to run the JCR TCK.</span>
<span style="color: red;">rhauch: Don't know if there is a UDDI TCK. Do you?</span>
<span style="color: blue;">maeste: No in fact</span>
<span style="color: blue;">maeste: I think there some interoperability meeting</span>
<span style="color: blue;">maeste: like ws-* ones</span>
<span style="color: blue;">maeste: not totally sure</span>
<span style="color: red;">rhauch: the graph API also is much simpler than JCR</span>
<span style="color: red;">rhauch: basically, it includes versioning.</span>
<span style="color: red;">rhauch: All other JCR functionality (e.g., namespaces, node types, activities, etc.) would all be done by working with graph nodes.</span>
<span style="color: red;">rhauch: JCR 2.0 is closer to this model ...</span>
<span style="color: red;">rhauch: moving closer to everything being accessible (and even editable) via JCR nodes.</span>
<span style="color: blue;">maeste: oki... 2.0 is much better on these aspects</span>
<span style="color: blue;">maeste: What about querying? Metamatrix engine?</span>
<span style="color: red;">rhauch: So I think if our graph API does versioning, then everything else can be done on top.</span>
<span style="color: blue;">maeste: I agree</span>
<span style="color: red;">rhauch: (I think versioning will be important for any persistence layer, which is why I think it has to be in the graph API.)</span>
<span style="color: red;">rhauch: I've talked generically about the graph API being "above the cache"</span>
<span style="color: red;">rhauch: but really parts if it would also be used by the connectors.</span>
<span style="color: red;">rhauch: things like property values, names, etc. are the same at the connector level too.</span>
<span style="color: red;">rhauch: I have a strawman SPI that I'm about ready to check in.</span>
<span style="color: red;">rhauch: (We chose "SPI" because it fits for use at the bottom, but we also thought the "API"s would be JCR or UDDI or something else.)</span>
<span style="color: red;">rhauch: I was working on it late last night, and came up with something I think is pretty cool.</span>
<span style="color: blue;">maeste: right</span>
<span style="color: red;">rhauch: basically, the connectors execute commands, where commands are things like "get node children" or "get node properties" or "create node" ...</span>
<span style="color: blue;">maeste: I'm anxious to have a look</span>
<span style="color: red;">rhauch: I'll let you know when it's in, because I'd love to get your feedback.</span>
<span style="color: blue;">maeste: command...because command pattern is used?</span>
<span style="color: red;">rhauch: yes</span>
<span style="color: blue;">maeste: so all command are rollbackable?</span>
<span style="color: blue;">maeste: IOW transaction compensation?</span>
<span style="color: red;">rhauch: Well, that's certainly my hope.</span>
<span style="color: red;">rhauch: I haven't taken it that far yet, but theoretically using commands should make rollbacks (and compensated transactions) easier.</span>
<span style="color: blue;">maeste: yep it was what I was thinking</span>
<span style="color: red;">rhauch: I've done that in other applications (rollbacks, not compensated txns)</span>
<span style="color: red;">rhauch: oh, regarding the JCR API</span>
<span style="color: red;">rhauch: depending upon how the JCR 2.0 spec shakes out</span>
<span style="color: red;">rhauch: (they're trying to make it backward compatible)</span>
<span style="color: red;">rhauch: if it is not perfectly compatible, we should be able to have separate JCR 1.0 and JCR 2.0 implementations.</span>
<span style="color: red;">rhauch: I'd hate for us to have to do this, but it's good to know it's possible.</span>
<span style="color: red;">rhauch: i hope this all makes sense</span>
<span style="color: blue;">maeste: all is very very interesting</span>
<span style="color: blue;">maeste: so next steps?</span>
<span style="color: blue;">maeste: you are checking the SPI in</span>
<span style="color: red;">rhauch: Well, the first is getting some SPI</span>
<span style="color: red;">rhauch: right.</span>
<span style="color: red;">rhauch: Then, we can proceed in a couple of directions.</span>
<span style="color: blue;">maeste: and then you are going to create issues?</span>
<span style="color: blue;">maeste: Or can we discuss now directions?</span>
<span style="color: red;">rhauch: 1) implementing the graph API on top of caching and on top of connectors.</span>
<span style="color: red;">rhauch: 2) implement some connectors</span>
<span style="color: red;">rhauch: 3) implement JCR API on top of graph SPI.</span>
<span style="color: red;">rhauch: (or at least part of the JCR API)</span>
<span style="color: red;">rhauch: I'd like to separate the caching from the federating logic.</span>
<span style="color: blue;">maeste: I agree 100%</span>
<span style="color: red;">rhauch: We should be able to run without a cache (not good for performance, but caching shouldn't really affect whether it works or not)</span>
<span style="color: blue;">maeste: yes of course (not only for performance, also for cluster)</span>
<span style="color: red;">rhauch: so 1) above will probably break up into several bigger JIRA tasks.</span>
<span style="color: red;">rhauch: yup</span>
<span style="color: blue;">maeste: yep</span>
<span style="color: blue;">maeste: about 2) what you have in mind?</span>
<span style="color: red;">rhauch: well, probably a connector to another JCR repository. That should be straightforward.</span>
<span style="color: blue;">maeste: yep</span>
<span style="color: red;">rhauch: Not sure we need others to get 1,2 & 3 working together.</span>
<span style="color: red;">rhauch: We'll want others for 0.2 release, like file system and SCM (for ESB & Guvnor)</span>
<span style="color: red;">rhauch: file system being exposing the files as nt:files and nt:folder</span>
<span style="color: blue;">maeste: yep</span>
<span style="color: red;">rhauch: That last one might be useful for testing.</span>
<span style="color: blue;">maeste: well one also for UDDI would be fine</span>
<span style="color: red;">rhauch: I'd also like 0.2 to have a JBDC metadata connector, for exposing database schemas through the repository.</span>
<span style="color: red;">rhauch: That's great demo stuff.</span>
<span style="color: blue;">maeste: yep u r right </span>
<span style="color: red;">rhauch: (plus it would get us a long way in the MetaMatrix user community)</span>
<span style="color: blue;">maeste: (I'm sure you are right...even if I don't know anything about metamatrix :( )</span>
<span style="color: red;">rhauch: No problem. :-)</span>
<span style="color: red;">rhauch: A few of the threads on the discussion forums had good use cases for federation,</span>
<span style="color: red;">rhauch: and interestingly they were all read-only.</span>
<span style="color: blue;">maeste: yep very intersting</span>
<span style="color: red;">rhauch: So I think we can get buy with no solving the updates until 0.3.</span>
<span style="color: blue;">maeste: yep, it simplify a lot of things</span>
<span style="color: red;">rhauch: Sure will.</span>
<span style="color: red;">rhauch: Anything I didn't cover?</span>
<span style="color: red;">rhauch: Looking back at your questions from earlier ...</span>
<span style="color: blue;">maeste: I don't think so. Point 3 is auto explaining</span>
<span style="color: red;">rhauch: Oh, we didn't talk about caching policy and parameters.</span>
<span style="color: blue;">maeste: right</span>
<span style="color: red;">rhauch: The doc covered this a bit, so not sure if you get the idea.</span>
<span style="color: red;">rhauch: I think the approach DNS uses will work really well.</span>
<span style="color: red;">rhauch: each fragment has a cache policy (with TTL, expiry time, etc.)</span>
<span style="color: red;">rhauch: and the federation engine respects those parameters.</span>
<span style="color: red;">rhauch: pretty simple.</span>
<span style="color: red;">rhauch: There was a dna-dev@ topic about that yesterday.</span>
<span style="color: blue;">maeste: yep I saw</span>
<span style="color: blue;">maeste: it makes sense for me</span>
<span style="color: blue;">maeste: I know DNS protocol (not in deeper detail, but I have a general idea)</span>
<span style="color: blue;">maeste: BTW I just have got an idea about a demo</span>
<span style="color: red;">rhauch: I think it will also work well if we federate multiple DNA federated repositories.</span>
<span style="color: blue;">maeste: we can implement also a connector on apache access_log</span>
<span style="color: red;">rhauch: yeah? What's the idea?</span>
<span style="color: blue;">maeste: and sequence it to extract infos</span>
<span style="color: red;">rhauch: Oh, that's good!</span>
<span style="color: blue;">maeste: and do some statistic about</span>
<span style="color: blue;">maeste: I'm sure it would be good</span>
<span style="color: blue;">maeste: probably with a little work also for an application concurrent to aw-stat ;)</span>
<span style="color: red;">rhauch: 0.2 should also have the event system, so the connector could publish events as the log is updated.</span>
<span style="color: blue;">maeste: yep</span>
<span style="color: blue;">maeste: and when we will have views...........</span>
<span style="color: red;">rhauch: ah, and great example of an analysis</span>
<span style="color: blue;">maeste: aw-stats concurrent will be here</span>
<span style="color: blue;">maeste: yep</span>
<span style="color: red;">rhauch: oh, that reminds me of one other thing</span>
<span style="color: blue;">maeste: what about analyzer...03?</span>
<span style="color: red;">rhauch: about the graph API and sequencers/analysers</span>
<span style="color: red;">rhauch: I don't know if you noticed this, but there is a StreamSequencer interface in the SPI.</span>
<span style="color: red;">rhauch: and a more generic Sequencer interface in the 'dna-repository' project.</span>
<span style="color: blue;">maeste: yep I noticed</span>
<span style="color: red;">rhauch: Sequencer is much more powerful, but it uses the JCR node in its interface.</span>
<span style="color: blue;">maeste: and adaptors to works together</span>
<span style="color: red;">rhauch: Right.</span>
<span style="color: red;">rhauch: So right now, StreamSequencer doesn't depend on JCR, making it easier to implement and test.</span>
<span style="color: blue;">maeste: yep I saw</span>
<span style="color: red;">rhauch: But other sequencers may want to do more advanced things.</span>
<span style="color: red;">rhauch: Okay, so here's where the graph SPI comes in.</span>
<span style="color: blue;">maeste: of course</span>
<span style="color: red;">rhauch: If the Sequencing framework is changed to work against the graph SPI</span>
<span style="color: blue;">maeste: are yop thinking to Graèh API dependent sequencer?</span>
<span style="color: red;">rhauch: yes ... your faster typist than me.</span>
<span style="color: blue;">maeste: lol</span>
<span style="color: red;">rhauch: And analyses, too.</span>
<span style="color: blue;">maeste: I made more typo</span>
<span style="color: red;">rhauch: LOL</span>
<span style="color: red;">rhauch: Anyway, they'd work regardless of what connectors are used and what API implementation is used.</span>
<span style="color: blue;">maeste: they = StreamSequencer?</span>
<span style="color: red;">rhauch: Plus, since it's more generic, analyzers and sequencers would work against nodes that represent built-in JCR things (like node types, namespaces, activities, etc.) without doing anything special.</span>
<span style="color: red;">rhauch: all sequencers.</span>
<span style="color: blue;">maeste: oki</span>
<span style="color: red;">rhauch: StreamSequencers would still do what they do.</span>
<span style="color: red;">rhauch: but the StreamSequencerAdapter implementation would change.</span>
<span style="color: blue;">maeste: yep it is what I have understood reading code</span>
<span style="color: red;">rhauch: At that point, the SPI for sequencers would become more powerful.</span>
<span style="color: red;">rhauch: It's all about the graph.</span>
<span style="color: blue;">maeste: and it is what I have in mind when I wrote you my complimets for very elegant code</span>
<span style="color: red;">rhauch: (ooh, some of my semantic days coming back!)</span>
<span style="color: blue;">maeste: lol</span>
<span style="color: red;">rhauch: :-)</span>
<span style="color: red;">rhauch: anything else to touch on, or should we call it for today?</span>
<span style="color: blue;">maeste: oki, my last queston is about analysers: when do you plan to implement first?</span>
<span style="color: red;">rhauch: I dunno.</span>
<span style="color: red;">rhauch: I'll be flexible</span>
<span style="color: red;">rhauch: They're not too different than sequencers.</span>
<span style="color: blue;">maeste: oki</span>
<span style="color: red;">rhauch: In my mind, federation is more important, so if we don't have the bandwidth to do both, then federation should come first.</span>
<span style="color: red;">rhauch: however, if we have enough people to spread out, then we certainly can tackle them.</span>
<span style="color: blue;">maeste: ok, that's all...I'll post the transcript of this chat on dna-dev</span>
<span style="color: red;">rhauch: My preference, tho, is to do shorter releases with more focused functionality.</span>
<span style="color: blue;">maeste: and I will wait for spi checked in</span>
<span style="color: red;">rhauch: I'll get that in today.</span>
<span style="color: red;">rhauch: Question:</span>
<span style="color: blue;">maeste: and I'll take a look to jira issues to take some one</span>
<span style="color: blue;">maeste: shoot</span>
<span style="color: red;">rhauch: would you rather apply a patch, or do you think it is fine to check in?</span>
<span style="color: blue;">maeste: Well I'm not sure to have understood you question about patch...</span>
<span style="color: red;">rhauch: Okay, this commit wouldn't be invasive and wouldn't break anything, so it may not matter in this case.</span>
<span style="color: red;">rhauch: But I've seen projects post a patch (to a JIRA) that the author wants feedback on</span>
<span style="color: red;">rhauch: people download and apply the patch, give their feedback, and the author changes then commits.</span>
<span style="color: red;">rhauch: Alternatively, I can just commit it and you can look at it that way. :-)</span>
<span style="color: blue;">maeste: oki... here comes my question about your svn policy....</span>
<span style="color: blue;">maeste: all on trunk?</span>
<span style="color: blue;">maeste: we can use branches for that</span>
<span style="color: red;">rhauch: well, that's a good point.</span>
<span style="color: blue;">maeste: I have a great experience of svn in quite large team....</span>
<span style="color: blue;">maeste: svn could do a lot for us</span>
<span style="color: red;">rhauch: yeah, the larger the team, the more branches are the way to go.</span>
<span style="color: blue;">maeste: hmmm..not totally agree</span>
<span style="color: red;">rhauch: so you'd prefer to do all major development on branches?</span>
<span style="color: blue;">maeste: no absolutely not</span>
<span style="color: blue;">maeste: not major development</span>
<span style="color: blue;">maeste: but a specific development which need feedback yes</span>
<span style="color: red;">rhauch: ah, gotcha</span>
<span style="color: blue;">maeste: well...may I post my ideas about svn on dna-dev</span>
<span style="color: red;">rhauch: That'd be a great discussion topic.</span>
<span style="color: blue;">maeste: I can resume how I use svn in a lot of projects with plus and minus</span>
<span style="color: red;">rhauch: That'd be great.</span>
<span style="color: blue;">maeste: I think with a good use of svn solve a lot of problems</span>
<span style="color: red;">rhauch: okay, so action items:</span>
<span style="color: blue;">maeste: 2 post by me (svn and this chat)</span>
<span style="color: red;">rhauch: 1) I'll check on commit privileges</span>
<span style="color: blue;">maeste: yep</span>
<span style="color: red;">rhauch: 2) I'll introduce you to John.</span>
<span style="color: blue;">maeste: good</span>
<span style="color: red;">rhauch: 3) commit SPI (on trunk for now, or other?)</span>
<span style="color: blue;">maeste: well if it isn't invasive it's good on trunk</span>
<span style="color: blue;">maeste: or if you prefer create a branch with a good name ;)</span>
<span style="color: red;">rhauch: 4) I'll start putting in some JIRA tasks.</span>
<span style="color: blue;">maeste: yep, and I'll look at them</span>
<span style="color: red;">rhauch: I may do that, simply so that we can maybe try something else.</span>
<span style="color: red;">rhauch: something else if the SPI gets bad reviews. :-)</span>
<span style="color: blue;">maeste: :)</span>
17 years, 7 months
- 1
- 0
Reminder: new mailing lists for 'commits' and 'issues'
by Randall Hauch
This is just a reminder that we have new automated mailing lists that
you can subscribe to if you're interested in the changes in JIRA
issues or SVN. For details, see https://lists.jboss.org/mailman/listinfo/dna-issues
and https://lists.jboss.org/mailman/listinfo/dna-commits pages.
Regards,
Randall
17 years, 7 months
- 1
- 0
Source change events
by John P. A. Verhaeg
The getting started documentation discuss providing support for sources
to push change notifications to the DNA server to, for instance, trigger
when a source's cache should be expired in a federated repository. What
is the current thinking for how or what will be provided to facilitate this?
17 years, 7 months
- 2
- 2