Re: Philosophy/Codebase fixes



> > If you're not familiar with XP, this is a pretty reasonable "15 minute summary":
> > http://www.eng.mu.edu/corlissg/168Search.03F/n_extremeProgramming.html
> > If we were following more of that stuff (refactor constantly, don't
> > design too much up front, etc) we'd be doing a lot better. The whole
> > goal of the XP worldview is to make development more "agile". We need
> > that pretty badly right now.
> 
> Yeah, XP sounds cool. However, it seems to me that we sort of block on
> step 1:
>      1. Pick a user's story for your next task
> We really don't have any user stories, because we don't yet know how the
> user uses Yarrr.

Yup, that's one of the problems we want to work on addressing.
Definitely my fuckup.

> Furthermore, a persistent object really does belong to one and only one
> single session, so conceptually basically all functions would need the
> session objects, and you would need to pass the right session object.
> 
> > 4) Deletes should probably not get a JDBC connection and then manually
> > DELETE. See:
> > http://www.hibernate.org/hib_docs/v3/reference/en/html/querysql.html#querysql-cud
> > for an alternative. I also wonder if there's a way to do an HQL-ish
> > mass-delete (clearly we don't want to do an item by item delete using
> > session.delete()).
> 
> We're doing this because the hibernate (2.1) docs recommended against
> using hibernate for mass deletion. This might be better with hibernate
> 3.

Hibernate supposedly has a direct SQL mechanism that doesn't involve
fetching the JDBC connection. I'm not sure it does anything differently,
but its a Hibernate3 feature they publicized a lot.

> > 21) We should consider using SOAP instead of XML-RPC. XML-RPC is all
> > very well, but part of the mess we're getting is because we really
> > could use an object API. We don't have to use the complex parts of
> > SOAP, and Apache appears to have decent SOAP Java bindings.
> 
> A fine-grained object API is very likely to introduce a lot of latencies
> though. :(

Perhaps instead we can figure out how to have a much much smaller non-OO
"do everything you need in this call" API? We can probably add a
fine-grained object API later if we want one for the masses of little
utilities written for yarrr ;-)

> Also, neither xml-rpc or soap really have a "session", which is
> something I think we need. Right now each call is a totally separate
> entity. It would be nice if we could e.g. verify the user in the start
> of the session and then never have to do that again, or have the ability
> to cache stuff in the server during the lifetime of a session.

Yeah. I started writing XML-RPC "auth" methods, but got distracted.

-Seth




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]