[GitHub] [plc4x] chrisdutz commented on pull request #545: feat(plc4go): Implementing the correct reading of BOOL types

2023-01-09 Thread GitBox


chrisdutz commented on PR #545:
URL: https://github.com/apache/plc4x/pull/545#issuecomment-1375345033

   Always happy to help educate :-)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [DISCUSS] Having a in-person community meetup?

2023-01-09 Thread Christofer Dutz
Well … I was thinking of asking TAC and setting something up.
As I mentioned. That would be quite a bit of work for me and the rest of the 
TAC folks.
So we’d only do it if offering this, would make a great difference.

Chris


From: Xiangdong Huang 
Date: Monday, 9. January 2023 at 08:51
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Having a in-person community meetup?
Ah... if there is TAC support, I will forward this message to IoTDB
community to see if there are committers want to join for the
Historian development face to face.

---
Xiangdong Huang
School of Software, Tsinghua University

Christofer Dutz  于2023年1月5日周四 18:59写道:
>
> Hi Jinlin,
>
> Would you be willing and able to attend such an event?
> You would be more than welcome.
>
> As I’m also part of the Apache Travel Assistance committee … I’d also like to 
> ask any others here too:
> Would you like to attend such an event, but the costs of travelling are what 
> you can’t afford or would have a too big impact on your budget to be willing 
> to come?
>
> Because there theoretically is the option of having Apache cover the costs 
> for travelling and accommodation. However, this would put quite a lot of 
> extra work for us for setting it up and running it.
> So, if it’s only 1-2 people, this probably doesn’t make much sense, but if 
> there were more, it might make sense.
>
> And please … don’t say: “I can’t afford it and would like assistance”, if the 
> problem is that the fuel has become too expensive for your Ferrari or the 
> parking costs for your private jet are skyrocketing ;-)
>
> And if you don’t want to publicly answer … feel free to DM me.
>
> Chris
>
>
> From: jl hong 
> Date: Thursday, 5. January 2023 at 02:16
> To: dev@plc4x.apache.org 
> Subject: Re: [DISCUSS] Having a in-person community meetup?
> This sounds exciting :)
>
> Jinlin
>
> Lukas Ott  於 2023年1月5日 週四 上午12:11寫道:
>
> > cool :-) would be fun so that I can finally ask all my questions in person
> > ;-)
> >
> > Am Mi., 4. Jan. 2023 um 16:37 Uhr schrieb Ben Hutcheson <
> > ben.hut...@gmail.com>:
> >
> > > Sounds like fun.
> > >
> > > Ben
> > >
> > > On Wed, Jan 4, 2023 at 4:30 PM Christofer Dutz <
> > christofer.d...@c-ware.de>
> > > wrote:
> > >
> > > > Ok …
> > > >
> > > > Uwe from codecentric FFM (the new office) was delighted my me asking if
> > > > codecentric would be willing to accommodate us during the hackathon.
> > > > So, that would be one option … I guess Sebastian would like that option
> > > ;-)
> > > >
> > > > Chris
> > > >
> > > >
> > > > From: Christofer Dutz 
> > > > Date: Wednesday, 4. January 2023 at 16:24
> > > > To: dev@plc4x.apache.org 
> > > > Subject: [DISCUSS] Having a in-person community meetup?
> > > > Hi all,
> > > >
> > > > some of you remember the times around our graduation. We had loads of
> > > > in-presence meetups and that really fuled the drive in the community.
> > > > Covid sort of was the opposite and it felt like we were sort of losing
> > > our
> > > > drive a bit.
> > > >
> > > > Now that Ben now also lives in Germany, I wanted to bring up this topic
> > > > again.
> > > >
> > > > What do you folks think of a 2-3-day hackathon on PLC4X (and possibly
> > the
> > > > Historian)?
> > > > Probably we would need to sort of do it Friday to Sunday.
> > > >
> > > > Also currently probing if we could not get TAC to help finance the
> > > travels
> > > > of everyone except me.
> > > >
> > > > Even if I would love a week on the Bahamas, probably something in
> > Germany
> > > > somewhere round Frankfurt or Stuttgart would make sense
> > > > (from the perspective of people being able to come there via public
> > > > transport and keeping the connection options simple and cheaper)
> > > >
> > > > What do you folks think.
> > > >
> > > >
> > > > Chris
> > > >
> > >
> >


Re: [DISCUSS] Refactor the PlcDriverManager in Java?

2023-01-09 Thread Christofer Dutz
So I noticed, while doing this

That the DriverManager has the two “getConnection” methods, but a load of 
others about listing drivers, accessing driver implementations etc.
So for now I settled with introducing a “PlcConnectionManager” interface and 
having the PlcDriverManager implement that (well … it already did)
This interface simply contains the two getConnection methods.

This way the CachedConnectionManager simply implements this interface and is 
exchangeable.

Chris



From: Łukasz Dywicki 
Date: Sunday, 8. January 2023 at 23:10
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Refactor the PlcDriverManager in Java?
Hey Chris,
I second approach with interfaces as it clearly cuts implementation and
declaration of operations. It could also help people who use OSGi
because making a PlcDriverManager valid osgi service will be easier
(lighter) with interface. It boils down to runtime where proxy for
interface type is built in JVM while proxy for class involves cglib/asm etc.

Best,
Łukasz

On 8.01.2023 15:35, Christofer Dutz wrote:
> Hi all,
>
> I’m currently working on a new Connection Cache for Java and have stumbled 
> over two things:
>
> The one is the fact, that the PlcDriverManager is a class and not an 
> interface.
> This makes it problematic for me to have the PlcDriverManager implement the 
> same interface.
> I could probably override every method, so this is not a big problem.
> However, having a PlcDriverManager interface would be the cleaner solution.
> This would require us to change the name of the current PlcDriverManager 
> class to something like DefaultPlcDriverManager… this would be a breaking 
> change.
>
> Another is that the getConnection doesn’t return a Future … the main reason 
> for this was the try-with-resources pattern, that automatically closes the 
> PlcConnection returned from getConnection.
> However, returning a future might be the better option and it would be more 
> like in the other languages.
> Especially when we’re working with cached connections. Here a client might be 
> waiting a while till it gets a connection handle.
> This also would be a breaking change.
>
>
> What do you folks think?
>
> Chris
>
>
>