Return-Path: X-Original-To: apmail-giraph-dev-archive@www.apache.org Delivered-To: apmail-giraph-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 81988DD54 for ; Thu, 8 Nov 2012 21:20:13 +0000 (UTC) Received: (qmail 80293 invoked by uid 500); 8 Nov 2012 21:20:13 -0000 Delivered-To: apmail-giraph-dev-archive@giraph.apache.org Received: (qmail 79908 invoked by uid 500); 8 Nov 2012 21:20:12 -0000 Mailing-List: contact dev-help@giraph.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@giraph.apache.org Delivered-To: mailing list dev@giraph.apache.org Received: (qmail 79889 invoked by uid 500); 8 Nov 2012 21:20:12 -0000 Delivered-To: apmail-incubator-giraph-dev@incubator.apache.org Received: (qmail 79886 invoked by uid 99); 8 Nov 2012 21:20:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Nov 2012 21:20:12 +0000 Date: Thu, 8 Nov 2012 21:20:12 +0000 (UTC) From: "Eli Reisman (JIRA)" To: giraph-dev@incubator.apache.org Message-ID: <997652509.88869.1352409612617.JavaMail.jiratomcat@arcas> In-Reply-To: <1434888928.71777.1352163852513.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (GIRAPH-409) Refactor / cleanups MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/GIRAPH-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493498#comment-13493498 ] Eli Reisman commented on GIRAPH-409: ------------------------------------ Nice, I like this stuff, great work! You know Jakob also mentioned a while back that his dream for the Vertex API is to have an interface eventually. As we move to being more flexible about what sort of input data we accept (such as the edge data), having the implementation possibilities for the data structures under the hood to be less vertex-centric than they look on the surface might be a real win. Couldn't agree more about changing the directory structure for clarity and for Maven's benefit, as well as improving the website and wiki docs. I am spread thin right now but looking forward to diving in on some of this stuff as windows of time open up! Thanks for opening this thread to discuss and refine these ideas going forward. It'll save time when we get down to implementing and reviewing the results! OK, gotta go...Thanks again! > Refactor / cleanups > ------------------- > > Key: GIRAPH-409 > URL: https://issues.apache.org/jira/browse/GIRAPH-409 > Project: Giraph > Issue Type: Improvement > Reporter: Nitay Joffe > Assignee: Nitay Joffe > Priority: Minor > > Some general thoughts I've jotted down while going through the code. Writing them here to start tracking progress for them. > 1. Refactor giraph.graph to giraph.master, giraph.worker. The whole giraph.graph package name is bad in general I think. > 2. Cleanup giraph.utils. For example move timers stuff to giraph.time. > 3. Change module names to be more maven-esque, that is something like giraph-root, giraph-core, giraph-formats. > 4. Remove WorkerClientServer. Is this needed anymore? > 5. Cleanup MasterThread#run: long convoluted method. > 6. Cleanup BspService#process: lots of duplication. Use a vector of events or something. > 7. Cleanup Vertex class: seems to me it has too many methods and should be a simpler interface (maybe even eventually an actual interface! not an abstract class). Add something like a Vertexes/Vertices class with helper methods that use can use. > 8. {Master,Worker}Observer. Discussed elsewhere already. ALlow users to easily plug in code at various points in the system. Essentially a cleaner implementation of e.g. WorkerContext > 9. Cleanup GraphMapper. I don't see why we even call a map() method seeing as we are overriding run(). We are clearly not particularly "mapreduce-y" so we should make it our entry point more clear than a map(). Also I think we should have something like a WorkerThread similar to MasterThread and clean up all of this to just creare whichever threads the node is assigned roles of. > 10. Move examples and anything else not needed for a giraph library out into it's own package (like giraph-examples)? > If someone +1s the ideas I'll work up some patches. Feel free to add other cleanup things here as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira